On Sat, 15 Feb 2020 at 05:36, Tom Lane wrote:
>
> Chapman Flack 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
On 02/14/20 18:43, Tom Lane wrote:
> I suppose it could be argued that that's a bug in the interpretation
> of role membership: arguably, if you're a member of some superuser
> role, that ought to give you membership in anything else. IOW, a
> superuser's implicit membership in every role isn't
I wrote:
> What I'm now thinking is that we shouldn't mess with the behavior of
> SET ROLE, as I mused about doing yesterday in [1]. It's spec-compliant,
> or close enough, so let's leave it be. On the other hand, changing the
> behavior of SET SESSION AUTHORIZATION is not constrained by spec
>
Chapman Flack 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
On 2/14/20 4:01 PM, Tom Lane wrote:
> Robert Haas 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
[ Starting a new thread about this, since the old one about GUC reporting
is only marginally related to this point ... if it were more so, maybe I'd
have found it when I went looking for it yesterday ]
Robert Haas writes:
> On Tue, Nov 5, 2019 at 10:02 AM Alvaro Herrera
> wrote:
>> There's a
