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
