Re: Failure to coerce unknown type to specific type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Postgres-Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Failure to coerce unknown type to specific type
Date: 2015-05-03 17:00:48
Message-ID: 16364.1430672448@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2015-05-03 17:13:51 Re: Failure to coerce unknown type to specific type
Previous Message Tom Lane 2015-05-03 14:16:58 Re: BUG #13224: Foreign key constraints cannot be changed to deferrable

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-03 17:13:51 Re: Failure to coerce unknown type to specific type
Previous Message Andrew Dunstan 2015-05-03 16:59:34 Re: CTE optimization fence on the todo list?