Re: Standards compliance of SET ROLE / SET SESSION AUTHORIZATION

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Standards compliance of SET ROLE / SET SESSION AUTHORIZATION
Date: 2020-02-14 21:19:57
Message-ID: e62d7d78-1724-11bd-75cf-b212cc7de029@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/14/20 4:01 PM, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> It wouldn't be difficult to introduce a new protocol-level option that
>> prohibits RESET SESSION AUTHORIZATION; and it would also be possible
>> to introduce a new protocol message that has the same effect as RESET
>> SESSION AUTHORIZATION. If you do those two things, then it's possible
>> to create a sandbox which the end client cannot escape but which the
>> pooler can escape easily.
> ...
> SET SESSION AUTHORIZATION foo PERMANENT;
> ... A protocol-level message
> to set session auth could also be possible, of course.

I'll once again whimper softly and perhaps ineffectually that an
SQL-exposed equivalent like

SET SESSION AUTHORIZATION foo WITH RESET COOKIE 'lkjhikuhoihkihlj';

would seem to suit the same purpose, with the advantage of being
immediately usable by any kind of front- or middle-end code the
instant there is a server version that supports it, without having
to wait for something new at the protocol level to trickle through
to n different driver implementations.

Regards,
-Chap

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-02-14 21:35:30 Re: Standards compliance of SET ROLE / SET SESSION AUTHORIZATION
Previous Message James Coleman 2020-02-14 21:14:01 Re: [DOC] Document auto vacuum interruption