Re: Virtual generated columns
От | Peter Eisentraut |
---|---|
Тема | Re: Virtual generated columns |
Дата | |
Msg-id | 64c2468c-3b69-44d7-863a-165931a70c1d@eisentraut.org обсуждение исходный текст |
Ответ на | Virtual generated columns (Peter Eisentraut <peter@eisentraut.org>) |
Список | pgsql-hackers |
On 15.01.25 15:12, Dean Rasheed wrote: > On Tue, 14 Jan 2025 at 13:37, Peter Eisentraut <peter@eisentraut.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.
В списке pgsql-hackers по дате отправления: