From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | Re: moving extraUpdatedCols out of RangeTblEntry (into ModifyTable) |
Date: | 2023-01-05 15:28:37 |
Message-ID: | 2488063.1672932517@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> On Thu, Jan 5, 2023 at 4:59 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joseph Koshakow | 2023-01-05 15:39:51 | Re: Infinite Interval |
Previous Message | Peter Eisentraut | 2023-01-05 15:15:21 | Re: Allow tailoring of ICU locales with custom rules |