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
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) |