> On 19 May 2020, at 23:07, Daniel Gustafsson <daniel@yesql.se> wrote:
>
>> 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 recent work on pg_dump reminded me about this thread, AFAICT this was never
addressed? Are you including it in the current line of work (if so, sorry for
missing it in the threads) or should I take a stab at it?
>>>> 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.
This patch still seems relevant for back-branches, but starting at 14 this time.
--
Daniel Gustafsson https://vmware.com/
