public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Mark Dilger <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Date: Tue, 16 Nov 2021 17:12:49 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CA+TgmobaKUYZhfXs-7kHjsmDmkcttH7-r9E2BJXUHtv9mkUUcw@mail.gmail.com>
	<[email protected]>
	<CA+TgmoYWqjpHEogdCEbRwzUb5ZoEaUt8ciNUXFCwLZDWBe+_BA@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Mark Dilger <[email protected]> writes:
> The patch already posted on this thread already works that way.  Robert and Tom seemed to infer that all gucs need to be present in the catalog, but in fact, not entering them in the catalog simply means that they aren't grantable.  I think the confusion arose from the fact that I created a mechanism for extension authors to enter additional gucs into the catalog, which gave the false impression that such entries were required.  They are not.  I didn't bother explaining that before, because Robert and Tom both seem to expect all gucs to be grantable, an expectation you do not appear to share.

The question is why you need pg_config_param at all, then.
AFAICS it just adds maintenance complexity we could do without.
I think we'd be better off with a catalog modeled on the design of
pg_db_role_setting, which would have entries for roles and lists
of GUC names that those roles could set.

BTW, another objection to pg_config_param as designed here is that
a "name" is not an appropriate way to store possibly-qualified
custom GUC names.  It's not long enough (cf. valid_custom_variable_name).

>> To support pg_dump and pg_upgrade, it might be better to have an
>> enabled/disabled flag rather than to delete rows.

> I'm not really sure what this means.

I didn't see the point of this either.  We really need to KISS here.
Every bit of added complexity in the catalog representation is another
opportunity for bugs-of-omission, not to mention a detail that you
have to provide mechanisms to dump and restore.

			regards, tom lane

view thread (67+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox