Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers

> The main change is a switch to using SPI for expression evaluation.  The plans are also cached along the same lines as the RI trigger plans.

I really dislike this implementation technique.  Aside from the likely

performance hit for existing triggers, I think it opens serious security

holes, because we can't fully guarantee that deparse-and-reparse doesn't

change the semantics.  For comparison, the RI trigger code goes to

ridiculous lengths to force exact parsing of the queries it makes,

and succeeds only because it needs just a very stylized subset of SQL.

With a generic user-written expression, we'd be at risk for several

inherently-ambiguous SQL constructs such as IS DISTINCT FROM (see

relevant reading at [1]).

 In general, users may expect that

once those are parsed by the accepting DDL command, they'll hold still,

not get re-interpreted at runtime.

...

(Relevant to that, I wonder why this patch is only concerned with

WHEN clauses and not all the other places where we forbid subqueries

for implementation simplicity.)

> b. If a WHEN expression is defined as "n = (SELECT ...)", there is the possibility that a user gets the error "more than one row returned by a subquery used as an expression" when performing DML, which would be rather cryptic if they didn't know there was a trigger involved.  To avoid this, we could disallow scalar expressions, with a hint to use the ANY/ALL quantifiers.

How is that any more cryptic than any other error that can occur

in a WHEN expression?