From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values |
Date: | 2023-02-22 09:07:44 |
Message-ID: | CAEZATCUrXMUK8F6daS_f0kH7o_=nDtEqA1Ny23SwHWbFvH61PA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, 22 Feb 2023 at 08:00, Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
>
> I have a minor question about the condition:
> + if (pt->commandType == CMD_INSERT ...
> Is it possible to get another commandType there?
Yes, there could also be ON INSERT DO ALSO UPDATE/DELETE rules. The
new code is intended to apply only for DO ALSO INSERT .. SELECT rules
(where the VALUES RTE in "pt" isn't in the usual place), but other
types of command in the rule are also possible. As long as the
top-level command is a multi-row INSERT ... VALUES (), (), ... it can
reach this code block.
For something like an ON INSERT DO ALSO UPDATE/DELETE rule, the
previous code should in theory handle any remaining DEFAULT values
from the top-level INSERT, though I'm not sure how thoroughly that has
been tested. I'll take a look.
> Thanks for the fix!
> (My extra testing discovered no new anomalies in this area.)
Thanks for testing.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2023-02-22 10:24:11 | Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware) |
Previous Message | Samo Dadela | 2023-02-22 09:04:04 | Re: pg_restore: warning: could not find where to insert IF EXISTS in statement "-- *not* dropping schema, since initdb creates it |