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
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) |
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 |