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.
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
