Re: [HACKERS] row description for domain in 7.4

2003-06-27 Thread Tom Lane
John DeSoi [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] row description for domain in 7.4

2003-06-27 Thread Peter Eisentraut
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   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] row description for domain in 7.4

2003-06-27 Thread John DeSoi
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.

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [HACKERS] row description for domain in 7.4

2003-06-26 Thread John DeSoi
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.

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [HACKERS] row description for domain in 7.4

2003-06-26 Thread Tom Lane
John DeSoi [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] row description for domain in 7.4

2003-06-26 Thread John DeSoi
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.

---(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


Re: [HACKERS] row description for domain in 7.4

2003-06-26 Thread Tom Lane
John DeSoi [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] row description for domain in 7.4

2003-06-26 Thread John DeSoi
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.

---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org


Re: [HACKERS] row description for domain in 7.4

2003-06-25 Thread Tom Lane
John DeSoi [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org