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
