On 12/10/16 19:59, Peter Eisentraut wrote:
>
> So functionality-wise, this looks pretty good, but there is some
> awkwardness in how to wire this into the existing facilities, since a
> server, also known as a foreign server, is currently tied to a foreign
> data wrapper. I have currently implemented this by creating a fake
> built-in foreign data wrapper called "subscription", so the actual
> syntax is
>
> CREATE SERVER node1 WRAPPER subscription OPTIONS (host '...', dbname
> '...');
>
> which isn't terrible, but still a bit weird.
Yuck.
>
> An idea is to make the foreign server concept more general and allow
> it to exist independently of a foreign data wrapper. Then create more
> specific syntax like
>
> CREATE SERVER node1 FOR SUBSCRIPTION OPTIONS ( ... );
>
> or
>
> CREATE SUBSCRIPTION SERVER ...
>
> This would work a bit like pg_constraint, which can be tied to a table
> or a type or even nothing (for the hypothetical assertions feature).
>
I think these two latter options sound better, I kinda wonder if it
should not be CREATE PUBLICATION SERVER though as the server represents
publication not subscription, but either way this is all reasonable I think.
> We'd need a separate mechanism for controlling which user has the right
> to create such subscription servers, but it might be acceptable at the
> beginning to just require superuserness.
>
Yes, superuser in the beginning, especially for subscriptions as it will
be bit harder to do proper checks without loss of performance. The good
part is that if we do superuser initially we can always add some GRANT
or ROLE later to lift the limitation so we don't have to build the whole
role model right from start.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services
