On Thu, Jun 5, 2025 at 08:32:44PM -0400, Bruce Momjian wrote: > On Wed, Jun 4, 2025 at 05:53:38PM -0400, Bruce Momjian wrote: > > On Wed, Jun 4, 2025 at 02:29:46PM -0700, Noah Misch wrote: > > > I agree with David G. Johnston's feedback on this. My draft didn't > > > mention > > > SECURITY DEFINER, because I consider it redundant from a user's > > > perspective. > > > If a function is SECURITY DEFINER, that always overrides other sources of > > > user > > > identity. No need to mention it each time. > > > > Well, if it is a SECURITY DEFINER function, it is not going to be run as > > the user who is active at commit/execution time, so I think we have to > > specify that. > > I came up with this text: > > Execute AFTER triggers as the role that was active when trigger > events were queued > > Previously such triggers were run as the role that was active at > trigger execution time (e.g., at COMMIT). This is significant > for cases where the role is changed between queue time and > transaction commit.
Item added to the incompatibilities section of the release notes. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
