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

From Alexander Lakhin
Subject Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values
Date
Msg-id 7f8f1bbb-9fb3-80fb-a400-5c7e755b5aa2@gmail.com
Whole thread Raw
In response to Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-bugs
21.02.2023 21:02, Tom Lane wrote:
> Dean Rasheed <dean.a.rasheed@gmail.com> writes:
>> Yeah, that makes sense. Something like this? (I think an elog() is
>> probably more useful than an Assert(), if we don't find what we
>> expect.)
> I think it's fine to leave the checks on parsetree->jointree being
> a FromExpr as Asserts, because that's assumed in a lot of places.
> Rest of it is OK by me.
I have a minor question about the condition:
+                if (pt->commandType == CMD_INSERT ...
Is it possible to get another commandType there?
IIUC, we cant get into
         if (defaults_remaining && product_queries != NIL)
only for INSERT ...
In other words, are there other commands that we expect executing
following lines for?
values_rte = rt_fetch(values_rte_index, pt->rtable);
...
rewriteValuesRTEToNulls(pt, values_rte);
(ALSO MERGE is not supported, as I can see)

If the (pt->commandType == CMD_INSERT) check is for safety, maybe it
should be broader?

Thanks for the fix!
(My extra testing discovered no new anomalies in this area.)

Best regards,
Alexander



pgsql-bugs by date:

Previous
From: Andrey Lepikhov
Date:
Subject: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware)
Next
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