Re: [HACKERS] UNION result
On Wed, 15 Jan 2003, Tom Lane wrote: > Stephan Szabo <[EMAIL PROTECTED]> writes: > > It seems to me that the spec has a fairly hardwired notion of what types > > should come out given the sql types. The biggest problems that I can > > see are that it doesn't extend well to an extensible type system and that > > in alot of cases it doesn't seem to allow conversions (for example > > select CAST(1 as float) union select '1' - if you were to allow > > conversions the rules seem to be ambiguous) > > Agreed, we can't make use of the spec's rules as anything much better > than "spiritual guidance". But it'd be nice if the rules we use match > what the spec says for the cases covered by the spec. In particular, > I think it's intuitively correct that numeric union int should yield > numeric no matter which order you write them in. > > Actually, now that I look at the code, 7.3 does in fact get this case > right, because we did add a check on pg_cast: it will prefer a type over > another if there is an implicit cast in only one direction. > The OP may have been fooled by this behavior: > > regression=# select 1 union select 1.0; And I was fooled by select '1' union select 1; because I'd forgotten that '1' isn't exactly a character string constant. select '1'::text union select 1; properly errors. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] UNION result
Stephan Szabo <[EMAIL PROTECTED]> writes: > It seems to me that the spec has a fairly hardwired notion of what types > should come out given the sql types. The biggest problems that I can > see are that it doesn't extend well to an extensible type system and that > in alot of cases it doesn't seem to allow conversions (for example > select CAST(1 as float) union select '1' - if you were to allow > conversions the rules seem to be ambiguous) Agreed, we can't make use of the spec's rules as anything much better than "spiritual guidance". But it'd be nice if the rules we use match what the spec says for the cases covered by the spec. In particular, I think it's intuitively correct that numeric union int should yield numeric no matter which order you write them in. Actually, now that I look at the code, 7.3 does in fact get this case right, because we did add a check on pg_cast: it will prefer a type over another if there is an implicit cast in only one direction. regression=# select 1 union select 1.2; ?column? -- 1 1.2 (2 rows) The OP may have been fooled by this behavior: regression=# select 1 union select 1.0; ?column? -- 1 (1 row) which happens because '1' and '1.0' are considered equal numeric values, even though they print differently. I'm not convinced that the UNION algorithm is right yet, but surely it's better than it was before. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] UNION result
On Wed, 15 Jan 2003, Tom Lane wrote: > Stephan Szabo <[EMAIL PROTECTED]> writes: > > Hmm, I think (but am not sure) that the spec bit > > in SQL92 that addresses this is 9.3 > > Set operation result data types based on the > > text in 7.10 query expression. It seems > > to say to me that should always be an > > approximate numeric (if 1.0 is an approximate > > numeric). Am I reading that right? > > Yeah, the existing algorithm for determining CASE/UNION result datatype > does not have any smarts about preferring numeric over integer, which is > what's missing to handle this case per-spec. > > There has been some speculation about junking the existing code (which > is mostly driven by a hardwired notion of "preferred types") in favor of > something driven by the contents of pg_cast. (At least I recall a > message or two about it, but I can't find it in the archives at the > moment.) It seems to me that the spec has a fairly hardwired notion of what types should come out given the sql types. The biggest problems that I can see are that it doesn't extend well to an extensible type system and that in alot of cases it doesn't seem to allow conversions (for example select CAST(1 as float) union select '1' - if you were to allow conversions the rules seem to be ambiguous) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] UNION result
Stephan Szabo <[EMAIL PROTECTED]> writes: > Hmm, I think (but am not sure) that the spec bit > in SQL92 that addresses this is 9.3 > Set operation result data types based on the > text in 7.10 query expression. It seems > to say to me that should always be an > approximate numeric (if 1.0 is an approximate > numeric). Am I reading that right? Yeah, the existing algorithm for determining CASE/UNION result datatype does not have any smarts about preferring numeric over integer, which is what's missing to handle this case per-spec. There has been some speculation about junking the existing code (which is mostly driven by a hardwired notion of "preferred types") in favor of something driven by the contents of pg_cast. (At least I recall a message or two about it, but I can't find it in the archives at the moment.) Nobody's made a specific proposal though --- and I'm more than a little bit worried about the possible speed penalty of turning what's presently a simple C switch-statement into a bunch of catalog lookups. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] UNION result
On Wed, 15 Jan 2003, Tatsuo Ishii wrote: > Does anybody know: > > select 1.0 union select 1; > or > select 1 union select 1.0; > > should return 1 or 1.0? Hmm, I think (but am not sure) that the spec bit in SQL92 that addresses this is 9.3 Set operation result data types based on the text in 7.10 query expression. It seems to say to me that should always be an approximate numeric (if 1.0 is an approximate numeric). Am I reading that right? ---(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] UNION result
Seems fine to me - the second select being cast to the type of the first select. Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Tatsuo Ishii > Sent: Wednesday, 15 January 2003 12:04 PM > To: [EMAIL PROTECTED] > Subject: [HACKERS] UNION result > > > Does anybody know: > > select 1.0 union select 1; > or > select 1 union select 1.0; > > should return 1 or 1.0? > > I see below on my Linux box: > > test=# select 1 union select 1.0; > ?column? > -- > 1 > (1 row) > > test=# select 1.0 union select 1; > ?column? > -- > 1.0 > (1 row) > > This seems a little bit inconsistent... > -- > Tatsuo Ishii > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] UNION result
I think the cause is that multi-type UNION queries use the first query for casting the other parts of the UNION. In the old days we would just reject the query because the UNION columns are of different types. --- Tatsuo Ishii wrote: > Does anybody know: > > select 1.0 union select 1; > or > select 1 union select 1.0; > > should return 1 or 1.0? > > I see below on my Linux box: > > test=# select 1 union select 1.0; > ?column? > -- > 1 > (1 row) > > test=# select 1.0 union select 1; > ?column? > -- > 1.0 > (1 row) > > This seems a little bit inconsistent... > -- > Tatsuo Ishii > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
