Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers
От | Robert Haas |
---|---|
Тема | Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers |
Дата | |
Msg-id | CA+TgmobuM2EMDmuL4Sv88OVFw8pKKuHPbHcXWhr4myPkMxYGSQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers ("Joe Wildish" <joe@lateraljoin.com>) |
Список | pgsql-hackers |
On Thu, Sep 23, 2021 at 5:34 AM Joe Wildish <joe@lateraljoin.com> wrote: > Regarding the deparse-and-reparse --- if I understand correctly, the core problem is that we have no way of going froma node tree to a string, such that the string is guaranteed to have the same meaning as the node tree? (I did try justnow to produce such a scenario with the patch but I couldn't get ruleutils to emit the wrong thing). Moreover, we couldn'tstore the string for use with SPI, as the string would be subject to trigger-time search path lookups. That prettymuch rules out SPI for this then. Do you have a suggestion for an alternative? I guess it would be go to the planner/executordirectly with the node tree? I think hoping that you can ever make deparse and reparse reliably produce the same result is a hopeless endeavor. Tom mentioned hazards related to ambiguous constructs, but there's also often the risk of concurrent DDL. Commit 5f173040e324f6c2eebb90d86cf1b0cdb5890f0a is a cautionary tale, demonstrating that you can't even count on schema_name.table_name to resolve to the same OID for the entire duration of a single DDL command. The same hazard exists for functions, operators, and anything else that gets looked up in a system catalog. I don't know what all of that means for your patch, but just wanted to get my $0.02 in on the general topic. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: