Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers
Date
Msg-id CA+TgmobuM2EMDmuL4Sv88OVFw8pKKuHPbHcXWhr4myPkMxYGSQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers  ("Joe Wildish" <joe@lateraljoin.com>)
List 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 by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Gather performance analysis
Next
From: Robert Haas
Date:
Subject: Re: Gather performance analysis