Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter)

Hi!
Thank you for comments, I’ll fix all inconsistencies in documentation.

> I don't understand this requirement. There are a bunch of
> password-less, still secured authentication that Postgres can use
> depending on the situations. To name one: peer. So this concept
> design looks rather broken to me.

It does look a bit awkward, maybe — unless you account for details.
For instance, you mention peer auth. Suppose we allow it, and there is nothing stopping the user from gaining superuser privileges by connecting locally.
Also, same requirements are in effect for FDW.

> Access to pg_subcription is still forbidden to non superusers, even
> with the patch. Shouldn't a user who has CREATE rights be able to
> dump his/her subscriptions?
>
> There is zero documentation about pg_user_subscriptions.

> Why? Cannot you store in catalogs the tables which can be used with a
> subscription, and then reuse the table list when connecting later.

That was my first thought too, but that approach made the implementation far too confusing. For insance, it requred an introduction of a new status for sync worker and a new statement to enable sync on particular tables.

> I find the concept behind this patch a bit confusing, and honestly I
> don't think that adding an extra per-relation filtering on the target
> server is a concept which compiles well with the existing logical
> replication because it is already possible to assign a subset of
> tables on the source, and linking a subscription to a publication means
> that this subset of tables will be used. Something which is more
> simple, and that we could consider is to lower the requirement for
> subscription creation to database owners, still this means that we give
> a mean to any database owner to trigger connections remote instances
> and spawn extra processes. This deserves more discussion, and there
> is the dump case which is not really covered.

--------
Efimkin Evgeny