Re: Wrong security context for deferred triggers?

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Noah Misch <noah@leadboat.com>

Cc: Laurenz Albe <laurenz.albe@cybertec.at>, Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@lists.postgresql.org

Date: 2025-06-05T16:45:51Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Doc: improve description of which role runs a trigger.
- c37be39a74b2 18.0 landed
Change role names used in trigger test.
- 4b05ebf0957b 18.0 landed
Ensure that AFTER triggers run as the instigating user.
- 01463e1cccd3 18.0 landed
Reverse the search order in afterTriggerAddEvent().
- 7921927bbb9d 18.0 landed

Noah Misch <noah@leadboat.com> writes:
> In postgr.es/m/1071973.1749075038@sss.pgh.pa.us of yesterday's release notes
> discussion, you wrote "Execute AFTER triggers as the role that was active at
> the moment the trigger event was queued."  That's a good direction, since it's
> correct for the mid-query case without raising it explicitly.  Maybe this way:

> +    Also, the trigger will always run as the role that queued the trigger
> +    event, unless the trigger function is defined as <literal>SECURITY
> +    DEFINER</literal>, in which case it will run as the function owner.

WFM.  I'd probably write "is marked as" not "is defined as".

			regards, tom lane