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

Поиск
Список
Период
Сортировка
От Alexander Lakhin
Тема Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values
Дата
Msg-id 7f8f1bbb-9fb3-80fb-a400-5c7e755b5aa2@gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andrey Lepikhov
Дата:
Сообщение: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware)
Следующее
От: Samo Dadela
Дата:
Сообщение: Re: pg_restore: warning: could not find where to insert IF EXISTS in statement "-- *not* dropping schema, since initdb creates it