Re: Non-superuser subscription owners - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Non-superuser subscription owners
Date
Msg-id CA+TgmoZA869xQ9w-DRL1eeV+yjuvGwcqPQLwodP7F27J6N+spA@mail.gmail.com
Whole thread Raw
In response to Re: Non-superuser subscription owners  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: Non-superuser subscription owners
Re: Non-superuser subscription owners
List pgsql-hackers
On Wed, Jan 18, 2023 at 3:58 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
> > On Jan 18, 2023, at 12:51 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > Unless I'm missing something, it seems like this could be a quite small patch.
>
> I didn't like the idea of the create/alter subscription commands needing to parse the connection string and think
aboutwhat it might do, because at some point in the future we might extend what things are allowed in that string, and
wehave to keep everything that contemplates that string in sync.  I may have been overly hesitant to tackle that
problem. Or maybe I just ran short of round tuits. 

I wouldn't be OK with writing our own connection string parser for
this purpose, but using PQconninfoParse seems OK. We still have to
embed knowledge of which connection string parameters can trigger
local file access, but that doesn't seem like a massive problem to me.
If we already had (or have) that logic someplace else, it would
probably make sense to reuse it, but if we don't, writing new logic
doesn't seem prohibitively scary. I'm not 100% confident of my ability
to get those rules right on the first try, but I feel like whatever
problems are there are just bugs that can be fixed with a few lines of
code changes. The basic idea that by looking at which connection
string properties are set we can tell what kinds of things the
connection string is going to do seems sound to me.

If there's some reason that it isn't, that would be good to discover
now rather than later.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Add LZ4 compression in pg_dump
Next
From: Pavel Stehule
Date:
Subject: Re: Re: Support plpgsql multi-range in conditional control