Re: Failure to coerce unknown type to specific type
От | Jeff Davis |
---|---|
Тема | Re: Failure to coerce unknown type to specific type |
Дата | |
Msg-id | 1430603756.2499.44.camel@jeff-desktop обсуждение исходный текст |
Ответ на | Re: Failure to coerce unknown type to specific type (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Failure to coerce unknown type to specific type
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: