On Tue, 7 Jul 2026 at 17:48, Jacob Champion <[email protected]> wrote:
> On Tue, Jul 7, 2026 at 2:21 PM Andrew Dunstan <[email protected]> wrote: > > I am really not a fan of implementing more and more little languages > inside Postgres. Doing so will incur a non-zero maintenance burden. > > Sure, but the status quo has its own self-compounding maintenance > burden, in which we'll either need to keep implementing little > languages (as with pg_hosts.conf) or else finally decide to refactor > I've had a few thoughts about this. I tend to lean towards JSON, in part because we already have it within Postgres. But the following applies to whatever syntax is adopted. Rather than having specific config files for different topics, which makes sense if each is pretty close to just being essentially a database table with rows and columns rather than a nested structure, could we have a single config file that does everything? Have a way to import other files, so if people want to break out their HBA definitions, for example, they could. So one could at one extreme have everything in one file, and at the other extreme the existing separate files could be broken out and each of those then broken up into many files concerning different parts of the configuration. To deal with compatibility with the existing config files, have specialized include directives that mean things like "import legacy X data from file F", by contrast with the normal include directives which would expect the files to be in the new format. Then all that is needed to keep using the existing files is to have a skeleton new-format file that essentially says "import legacy HBA from pg_hba.conf", "import legacy user name mappings from pg_ident.conf" and "import legacy GUC from postgresql.conf". Freeze the parsing of old-style files; new features and changes go only in the new format. This should eliminate (well, almost eliminate) the maintenance burden associated with having two file formats.
