On Thu, Feb 22, 2018 at 9:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes: > I hacked up an attempt to do this. It does seem to work in the very simple > case, but it does requiring changing the order in InitPostgres() to load > the startup packet before validating those.
I doubt that's safe. It requires, to name just one thing, an assumption that no processing done in process_startup_options has any need to know the database encoding, which is established by CheckMyDatabase. Thus for instance, if any GUC settings carried in the startup packet include non-ASCII characters, the wrong things will happen.
You could possibly make it work with more aggressive refactoring, but I remain of the opinion that this is a fundamentally bad idea anyhow. A GUC of this kind is just ripe for abuse, and I don't think it's solving any problem we really need solved.
Here's another attempt at moving this one forward. Basically this adds a new GucSource being GUC_S_CLIENT_EARLY. It now runs through the parameters once before CheckMyDatabase, with source set to GUC_S_CLIENT_EARLY. In this source, *only* parameters that are flagged as GUC_ALLOW_EARLY will be set, any other parameters are ignored (without error). For now, only the ignore_connection_restriction is allowed at this stage. Then it runs CheckMyDatabase(), and after that it runs through all the parameters again, now with the GUC_S_CLIENT source as usual, which will now process all other variables.