public inbox for [email protected]
help / color / mirror / Atom feedFrom: Mark Dilger <[email protected]>
To: Tom Lane <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Date: Tue, 16 Nov 2021 11:48:16 -0800
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]>
> On Nov 16, 2021, at 8:44 AM, Tom Lane <[email protected]> wrote:
>
> My concern is not about performance, it's about the difficulty of
> maintaining a catalog that expects to be a more-or-less exhaustive
> list of GUCs. I think you need to get rid of that expectation.
I'm preparing a new version of the patch that has the catalog empty to begin with, and only adds values in response to GRANT commands. That also handles the issues of extension upgrades, which I think the old patch handled better than the discussion on this thread suggested, but no matter. The new behavior will allow granting privileges on non-existent gucs, just as ALTER ROLE..SET allows registering settings on non-existent gucs.
The reason I had resisted allowing grants of privileges on non-existent gucs is that you can get the following sort of behavior (note the last two lines):
DROP USER regress_priv_user7;
ERROR: role "regress_priv_user7" cannot be dropped because some objects depend on it
DETAIL: privileges for table persons2
privileges for configuration parameter sort_mem
privileges for configuration parameter no_such_param
Rejecting "no_such_param" in the original GRANT statement seemed cleaner to me, but this discussion suggests pretty strongly that I can't do it that way. Changing the historical "sort_mem" to the canonical "work_mem" name also seems better to me, as otherwise you could have different grants on the same GUC under different names. I'm inclined to keep the canonicalization of names where known, but maybe that runs afoul the rule that these grants should not be tied very hard to the GUC?
> In the analogy to ALTER DATABASE/USER SET, we don't expect that
> pg_db_role_setting catalog entries will exist for all, or even
> very many, GUCs. Also, the fact that pg_db_role_setting entries
> aren't tied very hard to the actual existence of a GUC is a good
> thing from the maintenance and upgrade standpoint.
Doing it that way....
> BTW, if we did create such a catalog, there would need to be
> pg_dump and pg_upgrade support for its entries, and you'd have to
> think about (e.g.) whether pg_upgrade would attempt to preserve
> the same OIDs. I don't see any indication that the patch has
> addressed that infrastructure ... which is probably just as well,
> since it's work that I'd be wanting to reject.
Yeah, that's why I didn't write it. I wanted feedback on the basic implementation before doing that work.
> (Hm, but actually,
> doesn't pg_dump need work anyway to dump this new type of GRANT?)
Yes, if the idea of this kind of grant isn't being outright rejected, then I'll need to write that.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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