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

From Joe Wildish
Subject Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers
Date
Msg-id 78ce9a2a-5bba-4a39-b055-32f27031abc8@www.fastmail.com
Whole thread Raw
In response to Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers  ("Joe Wildish" <joe@lateraljoin.com>)
Responses Re: Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers
List pgsql-hackers
Hi Hackers,

Attached is a new version of this patch. I resurrected it after removing it from the commitfest last year; I'll add it back in to the next CF.

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.

Some random thoughts on the allowable expressions:

a. I originally disallowed functions and table-valued functions from appearing in the expression as they could potentially do anything and everything.  However, I noticed that we allow functions in FOR EACH ROW triggers so we are already in that position.  Do we want to continue allowing that in FOR EACH STATEMENT triggers?  If so, then the choice to restrict the expression to just OLD, NEW and the table being triggered against might be wrong.

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.

-Joe


Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: pg_stat_progress_create_index vs. parallel index builds
Next
From: Bharath Rupireddy
Date:
Subject: Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options