Re: PG 18 release notes draft committed
| От | David G. Johnston |
|---|---|
| Тема | Re: PG 18 release notes draft committed |
| Дата | |
| Msg-id | CAKFQuwa6rVaMDp5+hLbAMEefV-qP=8oCbsgiGnh4xPkQ=nu-wQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PG 18 release notes draft committed (Noah Misch <noah@leadboat.com>) |
| Ответы |
Re: PG 18 release notes draft committed
|
| Список | pgsql-hackers |
On Wed, Jun 4, 2025 at 3:17 PM Noah Misch <noah@leadboat.com> wrote:
On Wed, Jun 04, 2025 at 06:10:38PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> but you are right it is part of the function, not the
> > trigger:
>
> > Execute deferred constraint triggers attached to
> > non-SECURITY-DEFINER functions as the role that was active at
> > the time the trigger was fired
>
> > Previously such triggers were run as the role that was active at
> > commit/execution time.
> It's still inaccurate -- to my mind, a "deferred" trigger is one that
> runs later than the end of the triggering statement. I think you
> should use "after trigger".
Is this covering the case of executing at the end of an outer SQL command (thus not deferred) that contains volatile DML functions that temporarily change current_user within the function?
Also, "fired" is a fairly confusing
> choice of word here; I think most people would take that as meaning
> the act of running the trigger.
Agreed
How about
>
> Execute AFTER triggers as the role that was active at the
> moment the trigger event was queued
>
> Previously such triggers were run as the role that is active
> when it is time to execute the trigger (e.g., at COMMIT).
I like that.
I do as well.
David J.
В списке pgsql-hackers по дате отправления: