Thread: row description for domain in 7.4

row description for domain in 7.4

From
John DeSoi
Date:
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.



Re: row description for domain in 7.4

From
Tom Lane
Date:
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


Re: row description for domain in 7.4

From
John DeSoi
Date:
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.



Re: row description for domain in 7.4

From
Tom Lane
Date:
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


Re: row description for domain in 7.4

From
John DeSoi
Date:
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.



Re: row description for domain in 7.4

From
Tom Lane
Date:
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


Re: row description for domain in 7.4

From
John DeSoi
Date:
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.



Re: row description for domain in 7.4

From
Tom Lane
Date:
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


Re: row description for domain in 7.4

From
Peter Eisentraut
Date:
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



Re: row description for domain in 7.4

From
John DeSoi
Date:
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.