From: | Joseph Koshakow <koshy44(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Wrong security context for deferred triggers? |
Date: | 2024-06-23 02:21:20 |
Message-ID: | CAAvxfHcb_Wijv7s6FvqVCeNSDjg+UDNx9MuT=-3ZkMbbwvH=cQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jun 22, 2024 at 6:23 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> except invoker and triggerer are the same entity
Maybe "executor" would have been a better term than 'invoker". In this
specific example they are not the same entity. The trigger is
triggered and queued by one role and executed by a different role,
hence the confusion. Though I agree with Laurenz, special SQL syntax
for this exotic corner case is a little too much.
> Security definer on the function would take precedence as would its set
clause.
These trigger options seem a bit redundant with the equivalent options
on the function that is executed by the trigger. What would be the
advantages or differences of setting these options on the trigger
versus the function?
Thanks,
Joe Koshakow
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2024-06-23 03:13:09 | Re: Wrong security context for deferred triggers? |
Previous Message | David G. Johnston | 2024-06-22 22:22:25 | Re: Wrong security context for deferred triggers? |