From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Added schema level support for publication. |
Date: | 2021-01-19 11:41:55 |
Message-ID: | CALDaNm0wkqJE8B2voCConJfHLyYHPvt8xtyo0Ery9PiTvF0_=A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 9, 2021 at 8:08 PM Bharath Rupireddy <
bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
>
> As Amit pointed out earlier, the behaviour when schema dropped, I
> think we should also consider when schema is altered, say altered to a
> different name, maybe we should change that in the publication too.
>
This scenario is handled now in the patch posted at [1].
>
> Say a user has a schema with 121 tables in it, and wants to replicate
> only 120 or 199 or even lesser tables out of it, so can we have some
> skip option to the new syntax, something like below?
> CREATE PUBLICATION production_publication FOR ALL TABLES SCHEMA
> production WITH skip = marketing, accounts, sales; --> meaning is,
> replicate all the tables in the schema production except marketing,
> accounts, sales tables.
I have not yet handled this, I'm working on this and will try post a patch
for this in the next version.
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2021-01-19 11:45:05 | Re: Printing backtrace of postgres processes |
Previous Message | James Hilliard | 2021-01-19 11:16:25 | [PATCH 1/1] Fix detection of pwritev support for OSX. |