Re: Non-superuser subscription owners

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Non-superuser subscription owners
Date: 2023-01-20 08:04:12
Message-ID: d538fba2e48ac45a3085812c2aaa483cb2805667.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2023-01-19 at 17:51 -0800, Andres Freund wrote:
> I don't think we need to support complicated restriction schemes
> around this
> now. I'm sure such needs exist, but I think there's more places where
> a simple
> "allowed/not allowed" suffices.

If we did follow a path like 3 (having some kind of other object
represent the connection string), then it would create two different
kinds of subscriptions that might be controlled different ways, and
there might be some rough edges. Might also be fine, or we might never
pursue 3.

I feel like my words are being interpreted as though I don't want this
feature. I do, and I'm happy Robert re-raised it. I'm just trying to
answer his questions about why I set the work down, which is that I
felt some groundwork should be done before proceeding to a documented
feature, and I still feel that's the right thing.

But (a) that's not a very strong objection; and (b) my efforts are
better spent doing some of that groundwork than arguing about the order
in which the work should be done. So, time permitting, I may be able to
put out a patch or two for the next 'fest.

--
Jeff Davis
PostgreSQL Contributor Team - AWS

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Geier 2023-01-20 08:34:26 Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE
Previous Message Masahiko Sawada 2023-01-20 07:55:41 Re: Add index scan progress to pg_stat_progress_vacuum