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

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: 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 08:00:01
Message-ID: 7f8f1bbb-9fb3-80fb-a400-5c7e755b5aa2@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

21.02.2023 21:02, Tom Lane wrote:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

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