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
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 |