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
Re: Failure to coerce unknown type to specific type |
Список | 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 по дате отправления: