Re: Extension ownership and misuse of SET ROLE/SET SESSIONAUTHORIZATION

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Extension ownership and misuse of SET ROLE/SET SESSIONAUTHORIZATION
Дата
Msg-id DF141796-500F-4A3B-8217-A0368AC35FAC@yesql.se
обсуждение исходный текст
Ответ на Re: Extension ownership and misuse of SET ROLE/SET SESSION AUTHORIZATION  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Extension ownership and misuse of SET ROLE/SET SESSION AUTHORIZATION  (Daniel Gustafsson <daniel@yesql.se>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Two fsync related performance issues?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_stat_wal_receiver and flushedUpto/writtenUpto