Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values

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

In response to

Responses

Browse pgsql-bugs by date

  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