From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: why can't a table be part of the same publication as its schema |
Date: | 2022-09-09 06:14:51 |
Message-ID: | 37271.1662704091@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> To avoid these confusions, we have disallowed adding a table if its
> schema is already part of the publication and vice-versa.
Really?
Is there logic in ALTER TABLE SET SCHEMA that rejects the command
dependent on the contents of the publication tables? If so, are
there locks taken in both ALTER TABLE SET SCHEMA and the
publication-modifying commands that are sufficient to prevent
race conditions in such changes?
This position sounds quite untenable from here, even if I found
your arguments-in-support convincing, which I don't really.
ISTM the rule should be along the lines of "table S.T should
be published either if schema S is published or S.T itself is".
There's no obvious need to interconnect the two conditions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2022-09-09 06:44:25 | Re: Switching XLog source from archive to streaming when primary available |
Previous Message | John Naylor | 2022-09-09 05:59:09 | Re: Minimum bison and flex versions |