| From: | Ludek Finstrle <luf(at)pzkagis(dot)cz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-interfaces(at)postgresql(dot)org, pgsql-odbc(at)postgresql(dot)org |
| Subject: | Re: [ODBC] BLOB handling compatibility with PostgreSQL > 7.4 |
| Date: | 2005-12-06 19:27:49 |
| Message-ID: | 20051206192749.GA24711@soptik.pzkagis.cz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-interfaces pgsql-odbc |
> > I don't want to reinvent the wheel.
>
> Why do you feel a need to distinguish the domain from its underlying
> type on the client side? They're the same as regards representation
> and so on.
I need to determine wheter to use lo_import for large objects.
There is implementation in ODBC used type named "lo" (comapring type
oid). Type oid doesn't represent only large objects.
> what representation to use etc. Distinguishing domains made their job
> harder not easier.
I agree with you except lo implementation in ODBC ;-)
> If you want an add-on datatype that is really different from OID, then
> make a real datatype (CREATE TYPE). You can still piggyback on OID as
> the representation type --- steal its I/O functions and so on.
Does it cover lo_export which need oid as second parameter?
I'm sorry I'm new in using large objects and creating new types.
Thanks a lot
Luf
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steve Howe | 2005-12-06 19:29:18 | Re: [ODBC] BLOB handling compatibility with PostgreSQL |
| Previous Message | Tom Lane | 2005-12-06 19:07:13 | Re: [ODBC] BLOB handling compatibility with PostgreSQL > 7.4 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steve Howe | 2005-12-06 19:29:18 | Re: [ODBC] BLOB handling compatibility with PostgreSQL |
| Previous Message | Tom Lane | 2005-12-06 19:07:13 | Re: [ODBC] BLOB handling compatibility with PostgreSQL > 7.4 |