Re: Improve documentation of publication privilege checks - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Improve documentation of publication privilege checks
Date
Msg-id CAKFQuwYO=F9Odm2j86BmSYVuyR_tyR899Oj+WVuGfhU=N_LCkw@mail.gmail.com
Whole thread Raw
In response to Re: Improve documentation of publication privilege checks  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Improve documentation of publication privilege checks
List pgsql-hackers
On Tue, Dec 23, 2025 at 4:43 PM Peter Smith <smithpb2250@gmail.com> wrote:
Hi Shlok/Chao-San.

How about this alternative wording:

  <para>
   To create a publication using any of <literal>FOR ALL TABLES</literal>,
   <literal>FOR ALL SEQUENCES</literal>, or
   <literal>FOR TABLES IN SCHEMA</literal>, the user must be a superuser.
   To alter a publication using <literal>ADD TABLE</literal>, the user must
   have ownership rights on the table.  To alter a publication using
   <literal>ADD TABLES IN SCHEMA</literal>, the user must be a superuser.
  </para>


I initially preferred Chao Li's version but upon deeper consideration I've settled on this variant.  The conjunctions in the other are nice, but I've come to like how create and alter are better separated here.  And the choice to list "add table" first breaks up the string of superuser required commands when switching from creating to altering.

Kinda feel we should start this with the individual table creation case though:

To create a publication using FOR TABLE, the user must have ownership rights on all listed tables.  To create a publication using any of ... the user must be a superuser.  To alter ...

The alter case likewise accepts multiple tables...

David J.


pgsql-hackers by date:

Previous
From: Dharin Shah
Date:
Subject: Re: Fwd: [PATCH] Add zstd compression for TOAST using extended header format
Next
From: Chao Li
Date:
Subject: Refactor replication origin state reset helpers