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');
>>> postgres=# alter subscription sub refresh publication ;
>>> NOTICE:  added subscription for table public.t
>>> 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);
> 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:

Reply via email to