> On 29 Oct 2021, at 20:00, Daniel Gustafsson wrote:
>
>> On 29 Oct 2021, at 18:04, Tom Lane wrote:
>> Daniel Gustafsson writes:
>
>>> This patch still seems relevant for back-branches, but starting at 14 this
>>> time.
>>
>> I think the appropriate thing to do is stick your patch into all b
> On 29 Oct 2021, at 18:04, Tom Lane wrote:
> Daniel Gustafsson writes:
>> This patch still seems relevant for back-branches, but starting at 14 this
>> time.
>
> I think the appropriate thing to do is stick your patch into all branches
> for the moment. We can remove it again whenever we inv
Daniel Gustafsson writes:
> On 13 Feb 2020, at 23:55, Tom Lane 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.
> The recent work on pg_dump reminded me about this thread, AFAI
> On 19 May 2020, at 23:07, Daniel Gustafsson wrote:
>
>> On 19 May 2020, at 17:34, Tom Lane wrote:
>>
>> Daniel Gustafsson writes:
On 13 Feb 2020, at 23:55, Tom Lane wrote:
Given the current behavior of SET ROLE and SET SESSION AUTHORIZATION,
I don't actually see any way that
On Thu, Feb 13, 2020 at 5:55 PM Tom Lane wrote:
> (1) In the backend, allow SET ROLE to succeed if either the session
> userid or the current userid is a member of the desired role. This
> would mean that, given the use-case for --role that you are logging
> into an account that can "SET ROLE pos
> On 19 May 2020, at 17:34, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 13 Feb 2020, at 23:55, Tom Lane 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
Daniel Gustafsson writes:
>> On 13 Feb 2020, at 23:55, Tom Lane 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
> On 13 Feb 2020, at 23:55, Tom Lane wrote:
Is this being worked on for the 13 cycle such that it should be an open item?
> 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. SET SESSION AUTHO
pg_dump/restore fail to restore the ownership of an extension correctly:
in practice it'll always end up owned by whoever runs the restore
script. We've sort of averted our eyes from that up to now, because
it's not a big deal in a world where most extensions have to be
superuser-owned anyway. Bu
