Thread: row description for domain in 7.4
I created a domain with text as the data_type. When I get the row description message from the backend for a column using this domain, the type OID provided is for text (25) rather than the OID of the domain I created. I could have sworn I tested this in 7.3.x and the OID was for my domain. 7.4 bug or something I need to work out on my own? Thanks, John DeSoi, Ph.D.
John DeSoi <jd@icx.net> writes:
> I created a domain with text as the data_type. When I get the row
> description message from the backend for a column using this domain,
> the type OID provided is for text (25) rather than the OID of the
> domain I created. I could have sworn I tested this in 7.3.x and the OID
> was for my domain. 7.4 bug or something I need to work out on my own?
No, 7.4 intentional change. If you want to argue that this was a bad
idea, it's not too late ... but see the archived discussions about it.
regards, tom lane
On Wednesday, June 25, 2003, at 10:42 PM, Tom Lane wrote: > > No, 7.4 intentional change. If you want to argue that this was a bad > idea, it's not too late ... but see the archived discussions about it. > > Hi Tom, Can you give me a pointer on where to find the archived discussions? I have tried all the reasonable keywords I can think of in the archive search, but I can't seem to find anything. Thanks, John DeSoi, Ph.D.
John DeSoi <jd@icx.net> writes: > On Wednesday, June 25, 2003, at 10:42 PM, Tom Lane wrote: >> No, 7.4 intentional change. If you want to argue that this was a bad >> idea, it's not too late ... but see the archived discussions about it. > Can you give me a pointer on where to find the archived discussions? I Searching for "domain and protocol" seems to turn up most of the relevant messages, eg http://fts.postgresql.org/db/msg.html?mid=1062840 http://fts.postgresql.org/db/msg.html?mid=1046504 http://fts.postgresql.org/db/msg.html?mid=1365382 http://fts.postgresql.org/db/msg.html?mid=1368327 regards, tom lane
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.
John DeSoi <jd@icx.net> writes:
> My vote would be to restore the previous behavior and add
> connection-specific setting for clients that need it.
By my count you're in the minority --- there was no one lobbying
for reporting domain OIDs in the previous threads, and at least
two people strongly in favor of not doing so. While I don't have
a strong opinion about it myself, I don't have the interest to
make the behavior configurable, unless you can get some more votes
for your position.
regards, tom lane
On Thursday, June 26, 2003, at 11:22 PM, Tom Lane wrote: > > By my count you're in the minority --- there was no one lobbying > for reporting domain OIDs in the previous threads, and at least > two people strongly in favor of not doing so. While I don't have > a strong opinion about it myself, I don't have the interest to > make the behavior configurable, unless you can get some more votes > for your position. > > If I understand the change correctly, won't this break existing clients that use the previous behavior (even if they don't use the 3.0 protocol)? Since few people are using 7.4, I don't expect I'll get any more votes unless things start breaking down the road (when it will be too late to change anything). No hard feelings about it, but I'm really surprised existing behavior will be broken when the technical reasons for changing it were so weak. Did I mis-analyze the situation in the previous email? Is it not just one query to the database to get the base type compared to a lot more effort to get the domain? Thanks, John DeSoi, Ph.D.
John DeSoi <jd@icx.net> writes:
> No hard feelings about it, but I'm really surprised existing behavior
> will be broken when the technical reasons for changing it were so weak.
We've only had domains for one release cycle, so it seems to me that
there's not a lot of track record to justify a "this is how we've always
done it" position for domain-related behaviors. Especially when the
odds seem good that few people are really using domains. (Barry pointed
out that JDBC has been broken for the entire release cycle because it
couldn't handle I/O of domain types with the 7.3 RowDescription behavior
... but no one's complained to him yet ...)
I thought the rationale that client libraries would know about base
types but not domain types was pretty good, actually. From the
backend's perspective, reduction of domains to base types in
RowDescription takes extra code and extra cycles, so I'd have resisted
the argument if I had anything to stand on --- but I didn't. I'd say
your suggestion that the client side wants to distinguish domains from
base types is really the weaker end of the argument ...
regards, tom lane
John DeSoi writes: > 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. No, the whole point of domains is to restrict a datum (column, etc.) of a certain type to a subset of the allowable values. But the data is still of the same type, so it is generally inappropriate to treat it differently in the client or anywhere else where type identity matters. If you dig through the SQL standard, you will see this theme throughout. -- Peter Eisentraut peter_e@gmx.net
On Friday, June 27, 2003, at 02:00 AM, Tom Lane wrote: > We've only had domains for one release cycle, so it seems to me that > there's not a lot of track record to justify a "this is how we've > always > done it" position for domain-related behaviors. Especially when the > odds seem good that few people are really using domains. I was not aware it was such a new feature. So you are right, it probably won't have much impact. Is there any way to use the CREATE TYPE feature without having to write C functions? (I'm assuming here the row description would have to be the OID of the created type.) What I want to do is store text but know that the column is a specific text format so that it can be parsed properly by the front end. Thanks, John DeSoi, Ph.D.