[HACKERS] Shouldn't duplicate addition to publication be a no-op? - Mailing list pgsql-hackers

From Amit Langote
Subject [HACKERS] Shouldn't duplicate addition to publication be a no-op?
Date
Msg-id 64ec4f57-9361-d32c-ecbe-86158437cb7e@lab.ntt.co.jp
Whole thread Raw
Responses Re: [HACKERS] Shouldn't duplicate addition to publication be a no-op?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Shouldn't duplicate addition to publication be a no-op?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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).

create table bar (a int);
create publication mypub for table bar;
alter publication mypub add table bar;
ERROR:  relation "bar" is already member of publication "mypub"

2nd command should be a no-op, IMHO.

Consider the following (I know we're discussing inheritance elsewhere as
well):

create table foo (a int);
create table baz () inherits (foo);
alter table bar inherit foo;

alter table mypub add table foo;
ERROR:  relation "bar" is already member of publication "mypub"

There is no way to add foo and children other than bar to mypub without
doing so one-by-one.

If my proposal to make that a no-op sounds desirable, attached patch
implements that.

Thanks,
Amit

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Interval for launching the table sync worker
Next
From: Vitaly Burovoy
Date:
Subject: Re: [HACKERS] sequence data type