public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Mark Dilger <[email protected]>
Cc: Joshua Brindle <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Joe Conway <[email protected]>
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Date: Mon, 28 Mar 2022 17:54:28 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAGB+Vh4_UJsYHCWborm-y4CFt8gVvY_KbcNrpWcpXAk-GcwOtA@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<43857434-3f9b-3! [email protected]>
	<[email protected]>
	<[email protected]! m>
	<[email protected]>
	<9b37fa41-a068-81! ! ! [email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Mark Dilger <[email protected]> writes:
>> On Mar 28, 2022, at 2:16 PM, Tom Lane <[email protected]> wrote:
>> I just came across something odd in v12 that is still there in v13:
>> ExecGrant_Parameter uses InvokeObjectPostAlterHook not
>> InvokeObjectPostAlterHookArgStr.  This seems pretty inconsistent.
>> Is there a good argument for it?

> For SET and ALTER SYSTEM, the target of the action may not have an entry
> in pg_parameter_acl, nor an assigned Oid anywhere, so the only
> consistent way to pass the argument to the hook is by name.  For
> GRANT/REVOKE, the parameter must have an Oid, at least by the time the
> hook gets called.

Yeah, I know it's *possible* to make this work.  The question is why is
it good to do it like this rather than to use the string API, now that
we have the latter.  AFAICS this way just guarantees that the hook must
do a catalog lookup in order to figure out what you're talking about.

The core point here is that the actual identity of a GUC is its name.
Any OID that may exist in pg_parameter_acl is just a nonce alias that
means nothing to anybody.  Anyone who's trying to, say, enforce that
Joe Blow can't change shared_buffers is going to need to see the GUC
name.  (I am, btw, busy doing a lot of renaming in the patch to try
to clarify that these OIDs are not identifiers for GUCs; imagining
that they are just risks confusion.)

			regards, tom lane

view thread (81+ 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], [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