Re: PG 18 release notes draft committed

On Tue, Jun  3, 2025 at 10:21:23AM -0700, Noah Misch wrote:
> On Thu, May 01, 2025 at 10:44:50PM -0400, Bruce Momjian wrote:
> > I have committd the first draft of the PG 18 release notes.
> 
> When a commit changes the user that runs a function in existing queries, I
> think that almost always needs a release notes entry.  It would follow that
> commit 01463e1 needs an entry.  I recommend text "Run each deferred trigger as
> the role that caused the trigger to fire."

Okay, let's look at the commit:

    commit 01463e1cccd
    Author: Tom Lane <tgl@sss.pgh.pa.us>
    Date:   Thu Jan 23 12:25:45 2025 -0500
    
        Ensure that AFTER triggers run as the instigating user.
    
        With deferred triggers, it is possible that the current role changes
        between the time when the trigger is queued and the time it is
        executed (for example, the triggering data modification could have
        been executed in a SECURITY DEFINER function).
    
        Up to now, deferred trigger functions would run with the current role
        set to whatever was active at commit time.  That does not matter for
        foreign-key constraints, whose correctness doesn't depend on the
        current role.  But for user-written triggers, the current role
        certainly can matter.
    
        Hence, fix things so that AFTER triggers are fired under the role
        that was active when they were queued, matching the behavior of
        BEFORE triggers which would have actually fired at that time.
        (If the trigger function is marked SECURITY DEFINER, that of course
        overrides this, as it always has.)
    
        This does not create any new security exposure: if you do DML on a
        table owned by a hostile user, that user has always had various ways
        to exploit your permissions, such as the aforementioned BEFORE
        triggers, default expressions, etc.  It might remove some security
        exposure, because the old behavior could potentially expose some
        other role besides the one directly modifying the table.
    
        There was discussion of making a larger change, such as running as
        the trigger's owner.  However, that would break the common idiom of
        capturing the value of CURRENT_USER in a trigger for auditing/logging
        purposes.  This change will make no difference in the typical scenario
        where the current role doesn't change before commit.
    
        Arguably this is a bug fix, but it seems too big a semantic change
        to consider for back-patching.
    
        Author: Laurenz Albe <laurenz.albe@cybertec.at>
        Reviewed-by: Joseph Koshakow <koshy44@gmail.com>
        Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>
        Discussion: https://postgr.es/m/77ee784cf248e842f74588418f55c2931e47bd78.camel@cybertec.at

There are two questions --- should it be mentioned in the release notes,
and should it be listed in the incompatibility section.

It is called a bug fix, which I think means it is just implementing a
behavior that users already expected.  (Yes, there is a doc addition to
clarify this.)  I thought it was an edge case that didn't warrant
mention in the release notes, and the rare cases would be caught in
application testing.

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.

Seems like this would be in the incompatibility section, if we want to
add it.

-- 
  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.