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