Re: BUG #5240: Stable Functions that return a table type with a dropped column fail

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #5240: Stable Functions that return a table type with a dropped column fail
Дата
Msg-id 26408.1260727594@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #5240: Stable Functions that return a table type with a dropped column fail  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
[ just a note for the archives ]

I wrote:
> Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>> I don't think it's particularly closely related to #4907.

> Yeah.  I think the real problem is that set_subqueryscan_references
> is overly optimistic about how much work it has to do:

On further review it doesn't seem that fixing it there is very
practical.  Currently, the Vars in the SubqueryScan's tlist and quals
have varno referencing the subquery RTE and attno matching the column
numbers of the function's declared result type.  We can't just renumber
the attnos to match the actual subquery outputs without confusing the
heck out of EXPLAIN.  It would be okay to change the attnos to match
if we also changed the varno to be OUTER --- then EXPLAIN would
understand the Vars as being references to the subplan's tlist.  However
that would break the executor, in particular it would mean that
nodeSubqueryScan couldn't use the execScan.c facilities, since execScan
expects the expressions it's dealing with to reference the scan tuple
slot not the outer tuple slot.

I'm currently thinking that the best fix is to make inline expansion of
a SRF insert NULL columns into the expanded function tlist so that the
column numbering still matches up.  This probably means that we'd not be
able to inline in certain cases, like if the SRF contains a UNION or
other operation where modifying the tlist changes the semantics.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #5238: frequent signal 11 segfaults
Следующее
От: "Gerhard Lutz"
Дата:
Сообщение: BUG #5242: ODBC driver v8.4.1 crashed