Re: row literal problem - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: row literal problem
Date
Msg-id CAHyXU0zmJ6N6AGsZrzXcrHprrOgEoUF8GFamne-MZYCPRXFhqg@mail.gmail.com
Whole thread Raw
In response to Re: row literal problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: row literal problem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jul 20, 2012 at 1:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> I think the way to solve this is to do whatever it takes to get access
>> to the subplan targetlist.  We could then do something a bit cleaner
>> than what the named-rowtype code is currently doing: if there are
>> resjunk columns in the subplan targetlist, use the tlist to create a
>> JunkFilter, and then pass the tuples through that.  After that we can
>> insist that the tuples don't have any extra columns.
>
> Here's a draft patch for that.  It wasn't quite as ugly as I feared.
> A lot of the apparent bulk of the patch is because I chose to split
> ExecEvalVar into separate functions for the scalar and whole-row
> cases, which seemed appropriate because they now get different
> ExprState node types.

Thanks for that!  Applying the patch and confirming the fix turned up
no issues. I did a perfunctory review and it all looks pretty good:
maybe ExecInitExpr could use a comment describing the
InvalidAttrNumber check though...it's somewhat common knowledge that
InvalidAttrNumber means row variables but it's also used to initialize
variables before loops scans and things like that.

merlin


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: SP-GiST for ranges based on 2d-mapping and quad-tree
Next
From: Amit Kapila
Date:
Subject: Re: pgbench -i order of vacuum