Re: [HACKERS] logical replication connection information management

[Petr Jelinek]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] logical replication connection information management

[Alvaro Herrera]

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 Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, 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