> I'm not sure I've solidified my thoughts yet I can wait if you would prefer more time to think about the problem, I can work on other things in the meantime and we still have several months before the code freeze. I mainly wanted to share my findings with this experiment, and that was also a fun side project to try.
> 2) do you agree with the above? Yes. I'm fine with not verifying everything perfectly (or as close as perfectly as we can). I like my currently submitted version better than the child process verification version, but I wanted to see if it is doable or not, and to see what challenges there are. > But if someone decides in PG20 that > pam_use_hostname is a good GUC name for something, we're in trouble, > because the existing HBA options do not plug into the GUC system. We could make them reserved names? Or maybe even accessible as GUC variables, even if we leave the current parsing/validation logic as is. Making them proper GUC variables seemed like a clear follow up patch to me, even if not for pg19. > I'm worried that it's about to make a different decision from the > decision that is being made for the pg_hosts.conf file for SNI. I probably should read that thread in more detail, but I assume that your worry is about pg_hosts being a hardcoded configuration instead of using a similarly customizable GUC context? Shouldn't that be fixable in the future similarly? > 3) can your option (b) or (c) make enough use of existing GUC > infrastructure, so that a future PGC_HBA could easily subsume an > OAuth-specific solution, if people want to continue down that path in > a less OAuth-centric thread? I'm not sure about reusing existing GUC infrastructure, but I could make it look similar from the users perspective for example by adding a function DefineCustomValidatorStringVariable that has a similar interface to DefineCustomStringVariable, and in the future, this function could simply forward to DefineCustomStringVariable. That would limit the variable to be only definable in pg_hba, not postgresql.conf, but otherwise should work similarly for validators/users. I think this would be a larger patch than the real PGC_GUC, but it would be limited to the pg_hba parser. > 1) how close to the sun do you feel like flying today? Now that I have tried the PGC_HBA approach, I like how that works and integrates with everything, this is a much better solution than my original ideas. On the other hand, it would be great to get something working in PG19. By that time more libraries/tools should actually start to support oidc, and we will see more use of the feature, and the way we configure these parameters is important for the validators.
