Re: Added schema level support for publication.

From: Greg Nancarrow <gregn4422(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Smith <smithpb2250(at)gmail(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Subject: Re: Added schema level support for publication.
Date: 2021-09-22 01:27:47
Message-ID: CAJcOf-eQRKsucz7VqV5KNYUukHK7GvqMxUjTTC0sECWgT+zmng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 22, 2021 at 4:02 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> Attached v30 patch has the fixes for the same.
>

Thanks for all the patch updates.
I have some suggested updates to the v30-0005 documentation patch:

doc/src/sgml/ref/alter_publication.sgml
(1)
I'm thinking it might be better to simplify the description, because
it's a bit wordy and difficult to read with the "all tables in schema"
bits.
Suggested update is below (thoughts?):

BEFORE:
+ The first three variants change which tables and/or all tables in schema are
+ part of the publication. The <literal>SET</literal> clause will replace
+ the list of tables and/or all tables in schema in the publication with the
+ specified one, the existing tables and all tables in schema that were
+ present in the publication will be removed. The <literal>ADD</literal>
+ clause will add one or more tables and/or all tables in schema to the
+ publication. The <literal>DROP</literal> clauses will remove one or more
+ tables and/or all tables in schema from the publication. Note that adding
+ tables and/or all tables in schema to a publication that is already
+ subscribed to will require a <literal>ALTER SUBSCRIPTION ...
REFRESH PUBLICATION</literal>
+ action on the subscribing side in order to become effective.
AFTER:
+ The first three variants change which tables/schemas are
+ part of the publication. The <literal>SET</literal> clause will replace
+ the list of tables/schemas in the publication with the
+ specified list; the existing tables/schemas that were
+ present in the publication will be removed. The <literal>ADD</literal>
+ clause will add one or more tables/schemas to the
+ publication. The <literal>DROP</literal> clauses will remove one or more
+ tables/schemas from the publication. Note that adding
+ tables/schemas to a publication that is already
+ subscribed to will require a <literal>ALTER SUBSCRIPTION ...
REFRESH PUBLICATION</literal>
+ action on the subscribing side in order to become effective.

doc/src/sgml/ref/create_publication.sgml
(2)
I suggest an update similar to the following:

BEFORE:
+ Specifying a table that is part of schema specified in
+ <literal>FOR ALL TABLES IN SCHEMA</literal> option is not supported.
AFTER:
+ Specifying a table that is part of a schema already included in
the publication is not supported.

(3)
I find the following description a little unclear:

+ <para>
+ Specifying a schema along with schema's table specified as part of
+ <literal>FOR TABLE</literal> option is not supported.
+ </para>

Perhaps the following would be better:

+ <para>
+ Specifying a schema that contains a table already included in the
+ publication is not supported.
+ </para>

(4)
Minor fix:
BEFORE:
+ rights on the table. The <command>FOR ALL TABLES</command> and
+ <command>FOR ALL TABLES IN SCHEMA</command> clause requires the invoking
+ user to be a superuser.
AFTER:
+ rights on the table. The <command>FOR ALL TABLES</command> and
+ <command>FOR ALL TABLES IN SCHEMA</command> clauses require the invoking
+ user to be a superuser.

Regards,
Greg Nancarrow
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Chen 2021-09-22 01:30:50 Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
Previous Message Ajin Cherian 2021-09-22 01:12:13 Re: row filtering for logical replication