Re: BUG #5240: Stable Functions that return a table type with a dropped column fail - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #5240: Stable Functions that return a table type with a dropped column fail
Date
Msg-id 24858.1260581605@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #5240: Stable Functions that return a table type with a dropped column fail  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: BUG #5240: Stable Functions that return a table type with a dropped column fail  (Tom Lane <tgl@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>)
List 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 by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: BUG #5240: Stable Functions that return a table type with a dropped column fail
Next
From: Tom Lane
Date:
Subject: Re: BUG #5238: frequent signal 11 segfaults