Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: dgardner(at)creatureshop(dot)com ("David Gardner"), pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5240: Stable Functions that return a table type with a dropped column fail
Date: 2009-12-13 18:06:34
Message-ID: 26408.1260727594@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
[ just a note for the archives ]

I wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)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

In response to

pgsql-bugs by date

Next:From: Gerhard LutzDate: 2009-12-14 07:57:23
Subject: BUG #5242: ODBC driver v8.4.1 crashed
Previous:From: Tom LaneDate: 2009-12-13 16:58:11
Subject: Re: BUG #5238: frequent signal 11 segfaults

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group