Greetings, * Jeff Davis (pg...@j-davis.com) wrote: > Not all steps would be breaking changes, and a lot of those steps are > things we should do anyway. We could make it easier to write safe > SECURITY DEFINER functions, provide more tools for users to opt-out of > executing SECURITY INVOKER code, provide a way for superusers to safely > drop privileges, document the problems with security invoker and what > to do about them, etc.
Agreed. > But we also shouldn't exaggerate it -- for instance, others have > proposed that we run code as the table owner for logical subscriptions, > and that's going to break things in the same way. Arguably, if we are > going to break something, it's better to break it consistently rather > than one subsystem at a time. I tend to agree with this. > Back to the $SUBJECT, if we allow non-superusers to run subscriptions, > and the subscription runs the code as the table owner, that might also > lead to some weird behavior for triggers that rely on SECURITY INVOKER > semantics. Indeed. Thanks, Stephen
signature.asc
Description: PGP signature