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 | 24858.1260581605@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #5240: Stable Functions that return a table type with a dropped column fail (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: BUG #5240: Stable Functions that return a table type with a dropped column fail
Re: BUG #5240: Stable Functions that return a table type with a dropped column fail |
Список | pgsql-bugs |
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: * ... Notice we do * not do set_upper_references() here, because a SubqueryScan will * always have been created with correct references to its subplan's * outputs to begin with. The upper query will have Vars with attnos that correspond to the function's output rowtype, ie, 1,2,3,5 in this example. However the actual output of the lower query only has 4 columns. Kinda surprising we never hit this before, really, although I guess there are not that many cases where a subquery could have a named rowtype. regards, tom lane
В списке pgsql-bugs по дате отправления: