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 | 60780f8c-3132-133e-8286-538b732bff19@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values
|
Список | pgsql-bugs |
22.02.2023 12:07, Dean Rasheed wrote: > On Wed, 22 Feb 2023 at 08:00, Alexander Lakhin <exclusion@gmail.com> wrote: >> I have a minor question about the condition: >> + if (pt->commandType == CMD_INSERT ... >> Is it possible to get another commandType there? > Yes, there could also be ON INSERT DO ALSO UPDATE/DELETE rules. The > new code is intended to apply only for DO ALSO INSERT .. SELECT rules > (where the VALUES RTE in "pt" isn't in the usual place), but other > types of command in the rule are also possible. As long as the > top-level command is a multi-row INSERT ... VALUES (), (), ... it can > reach this code block. Thanks! I understand this place better now. I mistakenly supposed that VALUES RTE can intervene with INSERT only. But while exploring how they can affect other statements, I've found one more interesting thing: CREATE TABLE t (a int, b int DEFAULT -1); CREATE VIEW v AS SELECT * FROM t; CREATE RULE vr AS ON INSERT TO v DO ALSO INSERT INTO t SELECT NEW.b; INSERT INTO v VALUES(10, -1), (20, DEFAULT); SELECT * FROM v; a | b ----+---- 10 | -1 20 | -1 -1 | -1 | -1 It seems that a NEW field filled correctly if it is not DEFAULT, but DEFAULT is lost somehow. Best regards, Alexander
В списке pgsql-bugs по дате отправления: