Re: running logical replication as the subscription owner - Mailing list pgsql-hackers

From Jelte Fennema
Subject Re: running logical replication as the subscription owner
Date
Msg-id CAGECzQTGdVyYZ-fdvza=ryE5wJREWuG6YJ_t2VnfDNtdt4YmtA@mail.gmail.com
Whole thread Raw
In response to Re: running logical replication as the subscription owner  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: running logical replication as the subscription owner
List pgsql-hackers
> I don't get it. If we just return, that would result in skipping
> changes rather than erroring out on changes, but it wouldn't preserve
> the current behavior, because we'd still care about the table owner's
> permissions rather than, as now, the subscription owner's permissions.

Attached is an updated version of your patch with what I had in mind
(admittedly it needed one more line than "just" the return to make it
work). But as you can see all previous tests for a lowly privileged
subscription owner that **cannot** SET ROLE to the table owner
continue to work as they did before. While still downgrading to the
table owners role when the subscription owner **can** SET ROLE to the
table owner.

Obviously this needs some comments explaining what's going on and
probably some code refactoring and/or variable renaming, but I hope
it's clear what I meant now: For high privileged subscription owners,
we downgrade to the permissions of the table owner, but for low
privileged ones we care about permissions of the subscription owner
itself.

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Moving forward with TDE
Next
From: Peter Smith
Date:
Subject: Re: doc: add missing "id" attributes to extension packaging page