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

Поиск
Список
Период
Сортировка
От Joe Wildish
Тема Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers
Дата
Msg-id 78ce9a2a-5bba-4a39-b055-32f27031abc8@www.fastmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers  ("Joe Wildish" <joe@lateraljoin.com>)
Ответы Re: Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: pg_stat_progress_create_index vs. parallel index builds
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options