Re: Failure to coerce unknown type to specific type

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-02 21:55:56
Message-ID: 1430603756.2499.44.camel@jeff-desktop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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 can see two possibilities:

1. Resolve "u" from the subselect as text, and later fail to find a
match for +(text,int).
2. Resolve +(unknown, int) to +(int, int) first, then inform the
subselect that it's looking for an int (in the same way that you propose
the insert pass down some context).

I don't think the second one really makes sense though. For example:

select u+i, u||'suffix'::text from (select '1' as u, '2'::int as i) s;

In that case, "+" would be resolved to +(int, int) and || would be
resolved to ||(text, text). But "u" from the subselect can't be both an
int and text.

Then again, we probably want to fail a query like that anyway. So maybe
it does make sense as long as we can figure out a single type for "u",
and we fail otherwise.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message mario 2015-05-03 03:19:03 BUG #13220: make uninstall removes man pages not belonging to PostgreSQL
Previous Message Amit Kapila 2015-05-02 11:22:28 Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2015-05-02 23:09:46 Re: Make more portable TAP tests of initdb
Previous Message Joe Wildish 2015-05-02 21:42:24 Re: Implementing SQL ASSERTION