UNION result 
Author Message
 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://www.***.com/



Sun, 03 Jul 2005 12:04:38 GMT
 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.

---------------------------------------------------------------------------

Quote:

> 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

  +  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



Sun, 03 Jul 2005 12:14:10 GMT
 UNION result
Seems fine to me - the second select being cast to the type of the first
select.

Chris

Quote:
> -----Original Message-----


> Sent: Wednesday, 15 January 2003 12:04 PM

> 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



Sun, 03 Jul 2005 12:19:33 GMT
 UNION result

Quote:

> 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



Sun, 03 Jul 2005 14:19:03 GMT
 UNION result

Quote:

> 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



Sun, 03 Jul 2005 23:04:47 GMT
 UNION result

Quote:


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



Mon, 04 Jul 2005 00:18:51 GMT
 UNION result

Quote:

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



Mon, 04 Jul 2005 00:21:02 GMT
 UNION result

Quote:


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



Mon, 04 Jul 2005 01:01:03 GMT
 
 [ 8 post ] 

 Relevant Pages 

1. union results of stored procedures

2. Strange UNION results

3. How to JOIN with a UNION result set?

4. Getting DISTINCT from a SQL Union Result???

5. How can I sort tuples of a Union result set

6. Union Results in Temp Table Failed ??

7. How to UNION result set from two seperate SP?

8. Insert query results into a table and then union

9. NUMBER(9) UNION NUMBER(9) results in NUMBER(32,32)

10. Use UNION to combine results sets from EXEC'ing sp's

11. Union and Result set data

12. Enter a the results of a UNION Query into a TEMP TABLE


 
Powered by phpBB® Forum Software