Horton

Re: Wrong security context for deferred triggers?

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Joseph Koshakow <koshy44@gmail.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, pgsql-hackers@lists.postgresql.org, isaac.morland@gmail.com
Date: 2024-07-24T15:52:49Z
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 →

  1. Doc: improve description of which role runs a trigger.

  2. Change role names used in trigger test.

  3. Ensure that AFTER triggers run as the instigating user.

  4. Reverse the search order in afterTriggerAddEvent().

po 8. 7. 2024 v 14:36 odesílatel Laurenz Albe <laurenz.albe@cybertec.at>
napsal:

> On 7/8/24 04:14, Joseph Koshakow wrote:
> > Given the above and the fact that the patch is a breaking change, my
> > vote would still be to keep the current behavior and update the
> > documentation. Though I'd be happy to be overruled by someone with more
> > knowledge of triggers.
>
> Thanks for that feedback.
> Based on that, the patch should be rejected.
>
> Since there were a couple of other opinions early in the thread, I'll let
> it sit like that for now, and judgement can be passed at the end of the
> commitfest.  Perhaps somebody else wants to chime in.
>

It is hard to say what should be expected behaviour in this case. I think
the best is just to document this issue, and change nothing.

Regards

Pavel


>
> Yours,
> Laurenz Albe
>
>
>
>