Hello! MarkGUCPrefixReserved already attempts to mark a GUC prefix as owned by a specific shared library, but it only works partially: it removes remaining placeholders and emits an error if a later extension tries to use the same prefix.
What it does not do: * It does not detect the case where an extension loaded earlier already used something in that prefix, since there is currently no way to tell who declared a GUC variable before the prefix was reserved. * It does not enforce that an extension actually uses only its reserved prefixes. Both caused by the fact that this is an after-the-fact marker, not something that extensions have to setup before declaring variables. Since the intent of the function seems to be defining proper GUC prefix ownership for extensions—and since it would be good practice for extensions to follow this—I created a patch that improves this behavior. I didn't want to enforce anything by default, so this is controlled by a GUC variable: * The default is currently "off", which preserves the existing behavior. * "warning" generates warnings if: ** an extension used a reserved GUC prefix before another extension reserved it, ** an extension does not register any reserved prefixes, or ** it declares a GUC variable outside its reserved prefixes. * "prefix" keeps the warning if an extension does not reserve a prefix, but turns the other issues into errors. * "enforce" makes all of the above errors. I am not sure whether introducing another GUC is the best solution, but it is the best option I have found so far. The alternative would be to change the GUC API in some way—for example, by adding a new version of MarkGUCPrefixReserved, or an additional MakeSureGUCPrefixIsEmpty function that would opt an extension into stricter behavior. That approach would shift control from database administrators to extension developers; to me, giving administrators control seems preferable. At the moment, the default is "off", but perhaps it should be "warning". My hope is that the default strictness could increase over a few major releases. Currently, the patch does not restrict what the prefix can be, nor the number of prefixes. Restricting the number does not seem practical, as there are already extensions (including some in contrib) that reserve multiple prefixes. However, would it make sense to enforce that a prefix must either match the library name or start with it? Possibly as a separate option? Thoughts, would this be a useful feature?
0001-Guc-prefix-enforcement.patch
Description: Binary data
