Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values - Mailing list pgsql-bugs

From Dean Rasheed
Subject Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values
Date
Msg-id CAEZATCUrXMUK8F6daS_f0kH7o_=nDtEqA1Ny23SwHWbFvH61PA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-bugs
On Wed, 22 Feb 2023 at 08:00, Alexander Lakhin <exclusion@gmail.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



pgsql-bugs by date:

Previous
From: Samo Dadela
Date:
Subject: Re: pg_restore: warning: could not find where to insert IF EXISTS in statement "-- *not* dropping schema, since initdb creates it
Next
From: Richard Guo
Date:
Subject: Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware)