On 12/05/17 15:55, Neha Khatri wrote: > On 5/11/17, Petr Jelinek <petr.jeli...@2ndquadrant.com> wrote: >> Hi, >> >> On 11/05/17 14:25, tushar wrote: >>> Hi, >>> >>> I observed that -we cannot publish "foreign table" in Publication >>> >>> but same thing is not true for Subscription >>> >>> postgres=# create foreign table t (n int) server db1_server options >>> (table_name 't'); >>> CREATE FOREIGN TABLE >>> postgres=# alter subscription sub refresh publication ; >>> NOTICE: added subscription for table public.t >>> ALTER SUBSCRIPTION >>> >>> Is this an expected behavior ? if we cannot publish then how can we >>> add subscription for it. > > The above foreign table subscription succeeds only if the publisher > has published a same named normal table i.e. > create table t (n int); > CREATE PUBLICATION mypub FOR TABLE t; > > I think in current implemetation of LogicalRep. it is users > responsibility to match the table definition at publisher and > subscriber. Subscriber can not determine by itself what publisher has > defined. This usecase does not align with this assumption. > > >> However, the foreign tables indeed can't be subscribed. > > I suspect that a user would want to subcribe a foreign table in real world. > >> I think it does make sense to add check for this into CREATE/ALTER >> SUBSCRIBER though so that user is informed immediately about the mistake >> rather than by errors in the logs later. > > Yes, system should prohibit such operation though. > I tried to write to a patch to achieve this. It disalows subscription > of relation other than RELKIND_RELATION. > Attached is the patch. Comments? >
I sent my version of patch in parallel. I think we don't need to do the relation open like you did, all the info is in syscache. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers