Re: Privileges on PUBLICATION - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Privileges on PUBLICATION
Date
Msg-id a7b95f74-e3e3-adae-b472-2e8d24a4e4b8@enterprisedb.com
Whole thread Raw
In response to Re: Privileges on PUBLICATION  (Antonin Houska <ah@cybertec.at>)
Responses Re: Privileges on PUBLICATION
Re: Privileges on PUBLICATION
List pgsql-hackers
On 03.11.22 01:43, Antonin Houska wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
> 
>> The CF entry is about privileges on publications.  Please rebase that patch
>> and repost it so that the CF app and the CF bot are up to date.
> 
> The rebased patch (with regression tests added) is attached here.

Some preliminary discussion:

What is the upgrade strategy?  I suppose the options are either that 
publications have a default acl that makes them publicly accessible, 
thus preserving the existing behavior by default, or pg_dump would need 
to create additional GRANT statements when upgrading from pre-PG16.  I 
don't see anything like either of these mentioned in the patch.  What is 
your plan?

You might be interested in this patch, which relates to yours: 
https://commitfest.postgresql.org/40/3955/

Looking at your patch, I would also like to find a way to refactor away 
the ExecGrant_Publication() function.  I'll think about that.

I think you should add some tests under src/test/regress/ for the new 
GRANT and REVOKE statements, just to have some basic coverage that it 
works.  sql/publication.sql would be appropriate, I think.




pgsql-hackers by date:

Previous
From: Reid Thompson
Date:
Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends.
Next
From: Jérémie Grauer
Date:
Subject: new option to allow pg_rewind to run without full_page_writes