From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Petr Jelinek <petr(dot)jelinek(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: logical decoding and replication of sequences |
Date: | 2022-02-23 11:10:06 |
Message-ID: | CAA4eK1K81djyw3DgPw0GOZr9C1VPo6R2avHf0_qoOFnONNKJFw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 23, 2022 at 4:54 AM Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>
> 7) This updates psql to do roughly the same thing as for tables, so \dRp
> now list sequences added either directly or through schema, so you might
> get footer like this:
>
> \dRp+ testpub_mix
> ...
> Tables:
> "public.testpub_tbl1"
> Tables from schemas:
> "pub_test"
> Sequences:
> "public.testpub_seq1"
> Sequences from schemas:
> "pub_test"
>
> Maybe it's a bit too verbose, though. It also addes "All sequences" and
> "Sequences" columns into the publication description, but I don't think
> that can be done much differently.
>
> FWIW I had to switch the describeOneTableDetails() chunk dealing with
> sequences from printQuery() to printTable() in order to handle dynamic
> footers.
>
> There's also a change in \dn+ because a schema may be included in one
> publication as "FOR ALL SEQUENCES IN SCHEMA" and in another publication
> with "FOR ALL TABLES IN SCHEMA". So I modified the output to
>
> \dn+ pub_test1
> ...
> Publications:
> "testpub_schemas" (sequences)
> "testpub_schemas" (tables)
>
> But maybe it'd be better to aggregate this into a single line like
>
> \dn+ pub_test1
> ...
> Publications:
> "testpub_schemas" (tables, sequences)
>
> Opinions?
>
I think the second one (aggregated) might be slightly better as that
will lead to a lesser number of lines when there are multiple such
publications but it should be okay if you and others prefer first.
> 8) There's a shortcoming in the current grammar, because you can specify
> either
>
> CREATE PUBLICATION p FOR ALL TABLES;
>
> or
>
> CREATE PUBLICATION p FOR ALL SEQUENCES;
>
> but it's not possible to do
>
> CREATE PUBLICATION p FOR ALL TABLES AND FOR ALL SEQUENCES;
>
> which seems like a fairly reasonable thing users might want to do.
>
Isn't it better to support this with a syntax as indicated by Tom in
one of his earlier emails on this topic [1]? IIUC, it would be as
follows:
CREATE PUBLICATION p FOR ALL TABLES, ALL SEQUENCES;
> The problem is that "FOR ALL TABLES" (and same for sequences) is
> hard-coded in the grammar, not defined as PublicationObjSpec. This also
> means you can't do
>
> ALTER PUBLICATION p ADD ALL TABLES;
>
> AFAICS there are two ways to fix this - adding the combinations into the
> definition of CreatePublicationStmt, or adding FOR ALL TABLES (and
> sequences) to PublicationObjSpec.
>
I can imagine that adding to PublicationObjSpec will look compatible
with existing code but maybe another way will also be okay.
[1] - https://www.postgresql.org/message-id/877603.1629120678%40sss.pgh.pa.us
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Nitin Jadhav | 2022-02-23 13:28:14 | Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs) |
Previous Message | Daniel Gustafsson | 2022-02-23 10:31:01 | Re: Using Test::More test functions for pg_rewind |