Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable)
Date
Msg-id 2488063.1672932517@sss.pgh.pa.us
Whole thread Raw
In response to Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable)  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable)
List pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
> On Thu, Jan 5, 2023 at 4:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Here's a draft patch that does it like that.  This seems like a win
>> for more reasons than just pruning, because I was able to integrate
>> the calculation into runtime setup of the expressions, so that we
>> aren't doing an extra stringToNode() on them.

> Thanks for the patch.  This looks pretty neat and I agree that this
> seems like a net win overall.

Thanks for looking.

>> I've not looked into what it'd take to back-patch this.  We can't
>> add a field to ResultRelInfo in released branches (cf 4b3e37993),
>> but we might be able to repurpose RangeTblEntry.extraUpdatedCols.

> I think we can make that work.  Would you like me to give that a try?

I'm on it already.  AFAICT, the above won't actually work because
we don't have RTEs for all ResultRelInfos (per the
"relinfo->ri_RangeTableIndex != 0" test in ExecGetExtraUpdatedCols).
Probably we need something more like what 4b3e37993 did.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Allow tailoring of ICU locales with custom rules
Next
From: Joseph Koshakow
Date:
Subject: Re: Infinite Interval