Re: Adding OLD/NEW support to RETURNING
Dean Rasheed <dean.a.rasheed@gmail.com>
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: jian he <jian.universality@gmail.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-12T18:21:14Z
Lists: pgsql-hackers
Attachments
- support-returning-old-new-v4.patch (text/x-patch) patch v4
On Mon, 11 Mar 2024 at 14:03, Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > > Attached is an updated patch, fixing the seg-fault and now with > support for foreign tables. > Updated version attached tidying up a couple of things and fixing another bug: 1). Tidied up the code in createplan.c that was testing for old/new Vars in the returning list, by adding a separate function -- contain_vars_returning_old_or_new() -- making it more reusable and efficient. 2). Updated the deparsing code for EXPLAIN so that old/new Vars are always prefixed with the alias, so that it's possible to tell them apart in the EXPLAIN output. 3). Updated rewriteRuleAction() to preserve the old/new alias names in the rewritten query. I think this was only relevant to the EXPLAIN output. 4). Fixed a bug in assign_param_for_var() -- this needs to compare the varreturningtype of the Vars, otherwise 2 different Vars could get assigned the same Param. As the comment said, this needs to compare everything that _equalVar() compares, except for the specific fields listed. Otherwise a subquery like (select old.a = new.a) in the returning list would only generate one Param for the two up-level Vars, and produce the wrong result. 5). Removed the ParseState fields p_returning_old and p_returning_new that weren't being used anymore. Regards, Dean
Commits
-
doc: Updates for RETURNING OLD/NEW.
- 3ba9639e39ed 18.0 landed
-
Fix parsing of qualified relation names in RETURNING.
- 43830ecb8a9b 18.0 landed
-
Add OLD/NEW support to RETURNING in DML queries.
- 80feb727c869 18.0 landed
-
Remove useless casts to (void *)
- 7f798aca1d5d 18.0 cited
-
Refactor/reword some error messages to avoid duplicates
- 2bb969f39984 18.0 cited