Re: Failure to coerce unknown type to specific type

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Failure to coerce unknown type to specific type
Дата
Msg-id 16364.1430672448@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Failure to coerce unknown type to specific type  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Failure to coerce unknown type to specific type  (Jeff Davis <pgsql@j-davis.com>)
Re: Failure to coerce unknown type to specific type  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-bugs
Jeff Davis <pgsql@j-davis.com> writes:
> On Fri, 2015-05-01 at 10:08 -0700, Tom Lane wrote:
>> What really ought to happen here, IMO, is that the output columns of the
>> sub-select ought to get resolved to non-unknown types while we are doing
>> parse analysis of the sub-select.

> So, what would happen for something like:
>   select u+i from (select '1' as u, '2'::int as i) s;

I don't think there's any useful alternative to failing on this type of
case.  You can't realistically postpone resolution of the subquery output
types long enough for outer-level expression resolution to provide
context.  Even if you could, the behavior wouldn't be very well defined,
because (as you note) there might be more than one such expression leading
to contradictory results.

I think it's reasonable to try to let context inform resolution of the
subquery output types where there is exactly one immediate source of
context, such as the INSERT/SELECT case or UNION/INTERSECT/EXCEPT cases.
(Upthread, Kevin whines about our handling of UNION, but that's possibly
fixable.)

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #13224: Foreign key constraints cannot be changed to deferrable
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Failure to coerce unknown type to specific type