Bryn Jeffries <bryn.jeffr...@sydney.edu.au> writes:
> Tom Lane wrote
>> I think you might be able to do something with invoking untrusted code
>> inside a SECURITY DEFINER function. That context disables both SET ROLE
>> and SET SESSION AUTHORIZATION. I would not want to bet a lot on that
>> being bulletproof, however.
> Me neither. But out of interest, do you know what the intent was for the
> SESSION and LOCAL modifiers for SET ROLE?
> Both seem to do nothing more than regular SET ROLE, but are PostgreSQL
> extensions.
Those are just there because they're there for any SET <variable> command.
LOCAL means "set just for the duration of this transaction". SESSION is
only a noise word IIRC, ie, it lets you explicitly specify the default
behavior.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
