public inbox for [email protected]
help / color / mirror / Atom feedFrom: vignesh C <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Skipping schema changes in publication
Date: Mon, 18 Apr 2022 15:10:46 +0530
Message-ID: <CALDaNm1rS+tde7RSD0VSEbdmER6QmHVyZGz5MZ9KmBeDLY2JRA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CALDaNm3=JrucjhiiwsYQw5-PGtBHFONa6F7hhWCXMsGvh=tamA@mail.gmail.com>
<CALDaNm1G0=0J2O+6pMStKuWUjxJJT5vbO-5jiUqzYVZM_sJ2+w@mail.gmail.com>
<CALDaNm3Rc2KxGzLy-4qxFS+MWS6GN-ROVoPEb1MFA53W3iAqog@mail.gmail.com>
<[email protected]>
On Thu, Apr 14, 2022 at 7:18 PM Peter Eisentraut
<[email protected]> wrote:
>
> On 12.04.22 08:23, vignesh C wrote:
> > I have also included the implementation for skipping a few tables from
> > all tables publication, the 0002 patch has the implementation for the
> > same.
> > This feature is helpful for use cases where the user wants to
> > subscribe to all the changes except for the changes present in a few
> > tables.
> > Ex:
> > CREATE PUBLICATION pub1 FOR ALL TABLES SKIP TABLE t1,t2;
> > OR
> > ALTER PUBLICATION pub1 ADD SKIP TABLE t1,t2;
>
> We have already allocated the "skip" terminology for skipping
> transactions, which is a dynamic run-time action. We are also using the
> term "skip" elsewhere to skip locked rows, which is similarly a run-time
> action. I think it would be confusing to use the term SKIP for DDL
> construction.
>
> Let's find another term like "omit", "except", etc.
+1 for Except
> I would also think about this in broader terms. For example, sometimes
> people want features like "all columns except these" in certain places.
> The syntax for those things should be similar.
>
> That said, I'm not sure this feature is worth the trouble. If this is
> useful, what about "whole database except these schemas"? What about
> "create this database from this template except these schemas". This
> could get out of hand. I think we should encourage users to group their
> object the way they want and not offer these complicated negative
> selection mechanisms.
I thought this feature would help when there are many many tables in
the database and the user wants only certain confidential tables like
credit card information. In this case instead of specifying the whole
table list it will be better to specify "ALL TABLES EXCEPT
cred_info_tbl".
I had seen that mysql also has a similar option replicate-ignore-table
to ignore the changes on specific tables as mentioned in [1].
Similar use case exists in pg_dump too. pg_dump has an option
exclude-table that will be used for not dumping any tables that are
matching the table specified as in [2].
[1] - https://dev.mysql.com/doc/refman/5.7/en/change-replication-filter.html
[2] - https://www.postgresql.org/docs/devel/app-pgdump.html
Regards,
Vignesh
view thread (368+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Skipping schema changes in publication
In-Reply-To: <CALDaNm1rS+tde7RSD0VSEbdmER6QmHVyZGz5MZ9KmBeDLY2JRA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox