Re: Privileges on PUBLICATION - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Privileges on PUBLICATION
Date
Msg-id 485382af-1dff-b3b0-9ace-67bdd0082220@enterprisedb.com
Whole thread Raw
In response to Re: Privileges on PUBLICATION  (Antonin Houska <ah@cybertec.at>)
Responses Re: Privileges on PUBLICATION  (Antonin Houska <ah@cybertec.at>)
List pgsql-hackers
On 16.12.22 17:37, Antonin Houska wrote:
> This is v4. The patch had to be rebased due to the commit 369f09e420.

I think what this patch set needs first of all is a comprehensive 
description of what it is trying to do, exactly what commands and 
behaviors it adds, what are some of the subtleties and corner cases, 
what are open issues and questions.  Some of that can be pieced together 
from this thread, but it should really be put in one place somewhere, 
ideally in the commit message and/or the documentation.  (The main 0002 
patch does not have any documentation.)  It looks like you have a lot of 
bases covered, but without a full description, it's difficult to tell.

Some points on the details:

* You can combine all five patches into one.  I don't think they are 
meant to be applied separately.  The 0001 looks like it was maybe meant 
to be used separately, but it's not clear.  Again, the overall 
description would help.

* There is a lot of code that is contingent on am_db_walsender.  We 
should avoid that.  In most cases, it doesn't seem necessary.  Or at 
least document the reasons.

* The term "aware" (of a publication ACL, of a relation) is used a bunch 
of times.  That's not a technical term, and the meaning of those phrases 
is not clear.  Make sure the documentation/comments are precise.

* I don't think using SPI is warranted here.  You can get the required 
information directly from the underlying functions.

* The places the privileges are ultimately checked is too unprincipled. 
The 0001 patch overrides a very low-level function, but the 0002 on the 
other hand checks the privileges by digging through the query structures 
by hand instead of letting the executor do it.  We need to find ways to 
handle that that is more consistent with what the code is currently 
doing instead of adding more layers to it above and below.

* The misc_sanity.out test output means you need to add a TOAST table to 
pg_publication.




pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: An oversight in ExecInitAgg for grouping sets
Next
From: "Shinoda, Noriyoshi (PN Japan FSIP)"
Date:
Subject: RE: Perform streaming logical transactions by background workers and parallel apply