> On Jan 30, 2023, at 11:30 AM, Robert Haas <robertmh...@gmail.com> wrote:
>
> CREATE SUBSCRIPTION
> provides no tools at all for filtering the data that the subscriber
> chooses to send.
>
> Now that can be changed, I suppose, and a run-as user would be one way
> to make progress in that direction. But I'm not sure how viable that
> is, because...
>
>>> In what
>>> circumstances would be it be reasonable to give responsibility for
>>> those objects to different and especially mutually untrusting users?
>>
>> When public repositories of data, such as the IANA whois database, publish
>> their data via postgres publications.
>
> ... for that to work, IANA would need to set up the database so that
> untrusted parties can create logical replication slots on their
> PostgreSQL server. And I think that granting REPLICATION privilege on
> your database to random people on the Internet is not really viable,
> nor intended to be viable.
That was an aspirational example in which there's infinite daylight between the
publisher and subscriber. I, too, doubt that's ever going to be possible. But
I still think we should aspire to some extra daylight between the two. Perhaps
IANA doesn't publish to the whole world, but instead publishes only to
subscribers who have a contract in place, and have agreed to monetary penalties
should they abuse the publishing server. Whatever. There's going to be some
amount of daylight possible if we design for it, and none otherwise.
My real argument here isn't against your goal of having non-superusers who can
create subscriptions. That part seems fine to me.
Given that my work last year made it possible for subscriptions to run as
somebody other than the subscription creator, it annoys me that you now want
the subscription creator's privileges to be what the subscription runs as.
That seems to undo what I worked on. In my mental model of a
(superuser-creator, non-superuser-owner) pair, it seems you're logically only
touching the lefthand side, so you should then have a (nonsuperuser-creator,
nonsuperuser-owner) pair. But you don't. You go the apparently needless extra
step of just squashing them together. I just don't see why it needs to be like
that.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
