Re: UNION result

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.

In response to

Browse pgsql-hackers by date

  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