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
|
Список | 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 по дате отправления: