Tom,
Thanks for helping me find the previous discussion.
> 2) Better support for domains. Currently the jdbc driver is broken
> with
> regards to domains (although no one has reported this yet). The driver
> will treat a datatype that is a domain as an unknown/unsupported
> datatype. It would be great if the T response included the 'base'
> datatype for a domain attribute so that the driver would know what
> parsing routines to call to convert to/from the text representation the
> backend expects.
To me this seems completely wrong. The whole point of getting the
domain is so that I can know how I should parse the result coming from
the server. If I use a text domain, I can't distinguish the domain
column from any other text column and perform some other kind of
processing on the data.
If it remains as is, then the front end has to look up every column on
every request to see if that column corresponds to some domain. It
could possibly be cached to some degree, but it seems like
dropping/adding columns could result in the same a table oid, column
number pair having the same base type but a different domain.
As implemented previously, the front end only has to make one request,
one time, to determine the base type of the domain OID.
> - base type OID instead of user type OID. Might break some clients
> dealing with special types. ODBC users won't notice.
> - a postgresql.conf option to tell the backend to use base type OID or
> user type OID. Would catch most cases.
> - a connection specific setting to tell the backend to use base type
> OID
> or user type OID. For concurrent ODBC and weird clients use.
> - base type additionally in the RowDescription message. Obviously, this
> would break the 7.3 protocol.
My vote would be to restore the previous behavior and add
connection-specific setting for clients that need it. I don't think a
postgresql.conf option (alone) is viable because users might want to
use different kinds of front ends for the same server.
Best,
John DeSoi, Ph.D.
