From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com> |
Subject: | Re: Virtual generated columns |
Date: | 2025-01-15 19:37:58 |
Message-ID: | 64c2468c-3b69-44d7-863a-165931a70c1d@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 15.01.25 15:12, Dean Rasheed wrote:
> On Tue, 14 Jan 2025 at 13:37, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>>
>> Here is a new patch with that fixed and also a few
>> tweaks suggested by Jian.
>>
>
> I'm hoping to push my RETURNING OLD/NEW patch [1] soon, so I thought
> that I would check how it works together with this patch. The good
> news is that AFAICS everything just works, and it's possible to return
> old/new virtual generated columns in DML queries as expected.
>
> It did require a minor update, because my patch adds a new
> "result_relation" argument to ReplaceVarsFromTargetList() -- needed in
> DML queries because, when propagating a Var's old/new
> varreturningtype, replacement Vars need to be handled differently
> depending on whether or not they refer to the result relation. So that
> affects expand_generated_columns_internal(), when called from
> fireRIRrules(). OTOH, from expand_generated_columns_in_expr() it's OK
> to just pass 0 as the result relation index, because there won't be
> any old/new Vars in an expression that's not part of a DML query.
>
> Attached is the delta patch I used to handle this, along with a couple
> of simple test cases. It doesn't really matter which feature makes it
> in first, but the one that comes second will need to do something like
> this.
Ok, I'll wait if you want to go ahead with yours soon.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2025-01-15 19:46:26 | Re: Virtual generated columns |
Previous Message | Marcos Pegoraro | 2025-01-15 19:35:52 | Re: Eagerly scan all-visible pages to amortize aggressive vacuum |