Re: [ODBC] BLOB handling compatibility with PostgreSQL
От | Steve Howe |
---|---|
Тема | Re: [ODBC] BLOB handling compatibility with PostgreSQL |
Дата | |
Msg-id | 4395E68E.3000707@carcass.dhs.org обсуждение исходный текст |
Ответ на | Re: [ODBC] BLOB handling compatibility with PostgreSQL > 7.4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-interfaces |
Tom Lane wrote: >Ludek Finstrle <luf@pzkagis.cz> writes: > > >>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. > >The reason for the backend change was that client-side drivers (such as >JDBC and ODBC) want to know the underlying datatype so that they know >what representation to use etc. Distinguishing domains made their job >harder not easier. > > >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. > > A clear example situation in here is how to be able to distinguish a large object field. The ODBC driver, for instance, uses the 'lo' type, which is the same as an oid (Large Object). I ran into exactly the same situation as I wrote the pgExpress driver for Vita Voom Software: while declaring a domain looks like the clear choice, the original type's oid would be returned by the pq_ftype() function. So I based my solution more or less like this post by Hiroshi Saito: http://www.mail-archive.com/pgadmin-hackers@postgresql.org/msg01390.html ... and asked the users to create the 'lo' type that way, which would create a real type, just like Tom suggests. For more details on how it was implemented on the pgExpress, please check kits documentation: http://www.vitavoom.com/Products/pgExpress_Driver/docs/advanced_features.html#large_objects_declaration Best regards, Steve Howe
В списке pgsql-interfaces по дате отправления: