A grant or revoke on an unrecognized custom parameter will create a SUSET placeholder,
[...]
which cleans up the problem, with one exception: if the user executes a "revoke set on parameter some.such from public" prior to loading the module which defines parameter some.such, that revoke won't be retained. That doesn't seem entirely wrong to me, since no privilege to set the parameter existed when the revoke was performed, but rather was granted along with the creation of the parameter, but it also doesn't seem entirely right. Maybe revoke commands (but not grant commands) should error on unrecognized custom parameters?
The only revoke role target that makes sense here is the default grant given to public. Aside from that technicality the grant system is purely additive and so only the GRANTS end up retained so far as perpetual state is concerned.
For a revoke that doesn't target public we should remove the corresponding unrecognized setting grant if one is present. We don't generally/always raise a notice if a revoke doesn't actually cause something to be ungranted - though I'm partial to being so informed. I suppose we could distinguish the cases where the not-yet-loaded setting name is unrecognized by the system from the one where it is recognized but the grant is actually on a different role (or a revoke entry from public for the setting name is present).
For a revoke of an unknown setting from public we should keep an entry somewhere that tells the system that the default grant to public for that setting has been revoked. Maybe there isn't the same timing concern here as there is for GRANT, but if only for symmetry it seems like a good thing to implement.
I have the impression I'm missing something in what I wrote above but cannot quite figure out what. In any case as a first pass at this the behavior described is kinda what I'm expecting.
David J.
P.S.
Skimming the patch we are, to my agreement, not touching the ALTER DEFAULT PRIVILEGES command to work with this feature. Should the omission be noted explicitly? At least in the commit message I would think. Though the sentence in [1] "Also, these default privilege settings can be overridden using the ALTER DEFAULT PRIVILEGES command." is rendered only partially correct.
P.P.S.
+ The default privileges for a <literal>user</literal> parameter allow
+ <literal>PUBLIC</literal> to <command>SET</command> and
+ <command>RESET</command> the assigned value. By default,
+ <literal>PUBLIC</literal> has no privileges on
+ <literal>postmaster</literal>, <literal>superuser-backend</literal>,
+ <literal>internal</literal>, <literal>backend</literal>,
+ <literal>sighup</literal>, and <literal>superuser</literal> parameters.
Can we rephrase this to something like:
By default, PUBLIC has no privileges on parameters in the postmaster, ..., and superuser contexts.
pg_settings.context exists and those are the values found there. My initial interpretation of the wording was the postmaster, etc..., were themselves parameters, not containers for many parameters.
