On Mon, Nov 15, 2021 at 3:37 PM Mark Dilger <mark.dil...@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 and in the new system catalog > pg_config_param's .dat file. Failure to enter a GUC in the .dat file will > result in the inability to grant privileges on the GUC, at least unless/until > you run CREATE CONFIGURATION PARAMETER on the GUC. (This is, 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 complete > prototyping 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
