Bryn Jeffries <bryn.jeffries@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
