I implemented a DefineCustomValidatorStringVariable PoC - I don't like it that much. It adds too much boilerplate code for a very specific feature. If you say we should go with a more limited approach, I think my earlier simple version is better, because it is simple. I'll also try to think about other approaches.
And also let me go back to my concern that > Scoping validators to a specific prefix fixes the collision issue, but > it also goes in a different direction. I wrote this because of the simple "guc.some_name" example, as the fixed guc prefix - and previously I also looked into MarkGUCPrefixReserved, and I realized that there's no easy way to use that for enforcing prefixes for a library. And then I realized that maybe that needs an improvement, the behavior of MarkGUCPrefixReserved and DefineCustom*Variable seems like a legacy thing and not something that was intentionally designed that way. What do you think about the following patches? 0001: defines a new guc, guc_prefix_enforcement that potentially changes the behavior of prefix reservation. It has a few modes, based on which missing prefix reservations or variables defined outside the reserved prefix result in warnings or errors during library load time. This is unrelated to pgc_hba, and applies to all custom variables. 0002: the same patch as before, with your comment (su_backend, backend, suset, user can be set in pg_hba) addressed, and also always enforces proper prefix reservation for pg_hba variables using 0001. * We don't have to worry about collisions, because prefixes are always enforced in pg_hba, so people can't "redefine" the fixed key/value pairs or columns * It also introduces the idea of enforcing guc prefixes for extensions. In theory this setting should start with a relaxed default (I would say warning mode), and changed to strict in a later major version, enforcing proper guc rules by default. That way, third party extensions won't be able to define gucs like pam_use_hostname. I realize that 1. This is also scope creep 2. 0001 probably should be a separate thread/discussion But I first wanted to ask your opinion about the idea / what do you think about the interaction of the two patches.
0001-Guc-prefix-enforcement.patch
Description: Binary data
0002-Introduce-PGC_HBA-GUC-variables-settable-in-pg_hba.c.patch
Description: Binary data
