From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: UNION result |
Date: | 2003-01-15 16:33:30 |
Message-ID: | 20030115082609.A85240-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 15 Jan 2003, Tom Lane wrote:
> Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-01-15 16:35:30 | Re: inet regression test |
Previous Message | Lamar Owen | 2003-01-15 16:19:08 | Re: Anyone have a fresh Solaris 8 SPARC system to create |