On Mon, Nov 15, 2021 at 3:37 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
> One disadvantage of this approach is that the GUC variables are represented both in the list of C structures in guc.c
andin the new system catalog pg_config_param's .dat file. Failure to enter a GUC in the .dat file will result in the
inabilityto grant privileges on the GUC, at least unless/until you run CREATE CONFIGURATION PARAMETER on the GUC.
(Thisis, in fact, how extension scripts deal with the issue.) It would perhaps be better if the list of GUCs were not
duplicated,but I wasn't clever enough to find a clean way to do that without greatly expanding the patch (nor did I
completeprototyping any such thing.)
I think this imposes an unnecessary burden on developers. It seems
like it would be easy to write some code that lives inside guc.c and
runs during bootstrap, and it could just iterate over each
ConfigureNamesWhatever array and insert catalog entries for everything
it finds.
It's also going to be important to think about what happens with
extension GUCs. If somebody installs an extension, we can't ask them
to perform a manual step in order to be able to grant privileges. And
if somebody then loads up a different .so for that extension, the set
of GUCs that it provides can change without any DDL being executed.
New GUCs could appear, and old GUCs could vanish.
So I wonder if we should instead not do what I proposed above, and
instead just adjust the GRANT command to automatically insert a new
row into the relevant catalog if there isn't one already. That seems
nicer for extensions, and also nicer for core GUCs, since it avoids
bloating the catalog with a bunch of entries that aren't needed.
--
Robert Haas
EDB: http://www.enterprisedb.com