> On Jan 30, 2023, at 11:30 AM, Robert Haas <robertmhaas@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,
doubtthat's ever going to be possible. But I still think we should aspire to some extra daylight between the two.
PerhapsIANA doesn't publish to the whole world, but instead publishes only to subscribers who have a contract in place,
andhave agreed to monetary penalties should they abuse the publishing server. Whatever. There's going to be some
amountof 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
fineto me.
Given that my work last year made it possible for subscriptions to run as somebody other than the subscription creator,
itannoys me that you now want the subscription creator's privileges to be what the subscription runs as. That seems to
undowhat I worked on. In my mental model of a (superuser-creator, non-superuser-owner) pair, it seems you're logically
onlytouching 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
likethat.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company