Re: Standards compliance of SET ROLE / SET SESSION AUTHORIZATION

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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:35:30
Message-ID: 7581.1581716130@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> On 2/14/20 4:01 PM, Tom Lane wrote:
>> ... 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.

Yeah, I'm not that thrilled with the idea of a protocol message
that's not equivalent to any SQL-level functionality, either.

But the immediate point here is that I think we could get away with
playing around with SET SESSION AUTHORIZATION's semantics. Or,
seeing that that's just syntactic sugar for "SET session_authorization",
we could invent some new GUCs that allow control over this, rather
than new syntax.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2020-02-14 21:53:22 Re: Memory-Bounded Hash Aggregation
Previous Message Chapman Flack 2020-02-14 21:19:57 Re: Standards compliance of SET ROLE / SET SESSION AUTHORIZATION