From: | "Joe Wildish" <joe(at)lateraljoin(dot)com> |
---|---|
To: | "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Cc: | "Surafel Temesgen" <surafel3000(at)gmail(dot)com> |
Subject: | Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers |
Date: | 2021-06-02 12:19:17 |
Message-ID: | 78ce9a2a-5bba-4a39-b055-32f27031abc8@www.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
0001-Allow-queries-in-WHEN-expression-of-FOR-EACH-STATEME.patch | text/x-patch | 59.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2021-06-02 12:41:39 | Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options |
Previous Message | Tomas Vondra | 2021-06-02 11:56:55 | pg_stat_progress_create_index vs. parallel index builds |