On Thu, Apr 13, 2017 at 9:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
>> I wonder if trying to add a relation to a publication that it is already a
>> part should be considered a no-op, instead of causing an error (which
>> happens in the ALTER PUBLICATION ADD TABLES case).
>
> On what grounds?
>
> The equivalent case for inheritance is an error:
>
> regression=# create table foo (a int);
> CREATE TABLE
> regression=# create table bar () inherits (foo);
> CREATE TABLE
> regression=# alter table bar inherit foo;
> ERROR: relation "foo" would be inherited from more than once
Hmm, yes. Making it a no-op might be surprising to some.
> (Your example purporting to show the contrary contains a typo.)
Oops, I had meant: alter publication mypub add table foo;
> If there's a reason why this case should act differently from that
> precedent, you haven't shown it.
Maybe we won't solve it by doing what I proposed, but if there is a
database like this:
create table foo (a int);
create table bar () inherits(foo);
create publication mypub for table foo;
Dumping and restoring it into another database is not without errors,
because of the order in which things are dumped:
$ createdb test
$ pg_dump -s | psql -e test
<snip>
CREATE PUBLICATION mypub WITH (PUBLISH INSERT, PUBLISH UPDATE, PUBLISH DELETE);
ALTER PUBLICATION mypub ADD TABLE bar;
ALTER PUBLICATION mypub ADD TABLE foo;
ERROR: relation "bar" is already member of publication "mypub"
But perhaps that's a pg_dump issue, not this. I haven't closely
looked. Or perhaps something that will be resolved in the nearby
"Logical replication and inheritance" thread.
Thanks,
Amit
