Re: Custom oauth validator options

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.