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 15:54:12
Message-ID: 20030115075202.W84612-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:
> > 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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2003-01-15 16:05:25 inet regression test
Previous Message Tom Lane 2003-01-15 14:50:05 Re: UNION result