Peter Eisentraut wrote:
> 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 was with you until you mentioned pg_constraint, because as I
understand it we're not entirely happy with that one catalog. We've
talked about splitting it up into two catalogs for table and domain
constraints (I don't think we've considered assertions). Doing this
would cause us to drop the NOT NULL from pg_foreign_server.srvfdw.
However, while this sounds bad I think it's not *too* bad: it's not as
heavily used as the corresponding pg_constraint columns would be. In
other words, this raised some red flags with me initially but I think
it's okay.
> 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.
We'll need to have a better answer to this sooner rather than later.
Perhaps a new predefined grantable privilege?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services