Re: Granting SET and ALTER SYSTE privileges for GUCs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Date: 2021-11-16 15:28:57
Message-ID: 2226903.1637076537@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Nov 16, 2021 at 10:17 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Right. I think that any design that involves per-GUC catalog entries
>> is going to be an abysmal failure, precisely because the set of GUCs
>> is not stable enough.

> In practice it's pretty stable. I think it's just a matter of having a
> plan that covers the cases where it isn't stable reasonably elegantly.

Um. Really the point comes down to having sane default behavior
when there's no entry, which ought to eliminate any need to do the
sort of "run over all the entries at startup" processing that you
seemed to be proposing. So I guess I don't understand why such a
thing would be needed.

> We already embed GUC names in catalog entries when someone runs ALTER
> USER SET or ALTER DATABASE SET, so this proposal doesn't seem to be
> moving the goalposts in any meaningful way.

True; as long as the expectation is that entries will exist for only
a tiny subset of GUCs, it's probably fine.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-11-16 15:32:07 Re: Granting SET and ALTER SYSTE privileges for GUCs
Previous Message Mark Dilger 2021-11-16 15:24:51 Re: Granting SET and ALTER SYSTE privileges for GUCs