On 12/05/17 15:55, Neha Khatri wrote:
> On 5/11/17, Petr Jelinek <petr.jelinek@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
