Re: logical decoding and replication of sequences

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: 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-24 12:11:23
Message-ID: f8e76b08-833e-8e9a-4299-94470d501aa7@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 23.02.22 12:10, Amit Kapila wrote:
> 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;

I don't think there is any point in supporting this. What FOR ALL
TABLES was really supposed to mean was "everything you can get your
hands on". I think we should just redefine FOR ALL TABLES to mean that,
maybe replace it with a different syntax. If you want to exclude
sequences for some reason, there is already a publication option for
that. And FOR ALL SEQUENCES by itself doesn't make any sense in practice.

Are there any other object types besides tables and sequences that we
might want to logically-replicate in the future and whose possible
syntax we should think about? I can't think of anything.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2022-02-24 12:17:55 Re: Design of pg_stat_subscription_workers vs pgstats
Previous Message Amit Kapila 2022-02-24 12:05:26 Re: Design of pg_stat_subscription_workers vs pgstats