Re: Extension ownership and misuse of SET ROLE/SET SESSIONAUTHORIZATION - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Extension ownership and misuse of SET ROLE/SET SESSIONAUTHORIZATION
Date
Msg-id DF141796-500F-4A3B-8217-A0368AC35FAC@yesql.se
Whole thread Raw
In response to Re: Extension ownership and misuse of SET ROLE/SET SESSION AUTHORIZATION  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Extension ownership and misuse of SET ROLE/SET SESSION AUTHORIZATION
List pgsql-hackers
> On 19 May 2020, at 17:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>>> On 13 Feb 2020, at 23:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Given the current behavior of SET ROLE and SET SESSION AUTHORIZATION,
>>> I don't actually see any way that we could get these features to
>>> play together.
>
>> Is this being worked on for the 13 cycle such that it should be an open item?
>
> I didn't have it on my list, but yeah maybe we should add it to the
> "pre-existing issues" list.
>
>>> The quick-and-dirty answer is to disallow these switches from being
>>> used together in pg_restore, and I'm inclined to think maybe we should
>>> do that in the back branches.
>
>> ..or should we do this for v13 and back-branches and leave fixing it for 14?
>> Considering the potential invasiveness of the fix I think the latter sounds
>> rather appealing at this point in the cycle.  Something like the attached
>> should be enough IIUC.
>
> pg_dump and pg_dumpall also have that switch no?

They do, but there the switches actually work as intended and the combination
should be allowed AFAICT.  Since SET ROLE is sent to the source server and not
the output we can use for starting the dump without being a superuser.

cheers ./daniel


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Two fsync related performance issues?
Next
From: Michael Paquier
Date:
Subject: Re: pg_stat_wal_receiver and flushedUpto/writtenUpto