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
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 |