Re: UNION result

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: UNION result
Дата
Msg-id 5227.1042647002@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: UNION result  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Ответы Re: UNION result  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Список pgsql-hackers
Stephan Szabo <sszabo@megazone23.bigpanda.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.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Rod Taylor
Дата:
Сообщение: inet regression test
Следующее
От: Lamar Owen
Дата:
Сообщение: Re: Anyone have a fresh Solaris 8 SPARC system to create