On Wed, Jun 4, 2025 at 02:02:38PM -0700, David G. Johnston wrote:
> On Wed, Jun 4, 2025 at 1:45 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> Now, if we do want to mention it, it should be done in a way that makes
> it clear to readers whether they are affected by this change. We can
> try text like:
>
> Execute non-SECURITY-DEFINER AFTER triggers 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 time.
>
>
> "Deferred constraint triggers now run as the role active when the trigger was
> fired: previously they used the role active when execution began."
>
> The timing is not only at commit, and it makes more sense to me to focus on
> "deferred constraint" instead of the more general "after" trigger.
Ah, yes, I see your point --- it is really only deferred after triggers,
not before triggers, and deferrability is only available for constraint
triggers.
> The trigger doesn't have a security definer clause - the function does and
> would of course take effect during execution. Not strongly opposed to keeping
> the note.
I think we have to keep the non-SECURITY-DEFINER designation to keep the
text accurate, 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.
As you can see, this is going to be hard to read, and I don't know if a
sufficient number of people will care.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.