Re: Proposal: new file format for hba/ident/hosts configuration?
Zsolt Parragi <zsolt.parragi@percona.com>
From: Zsolt Parragi <zsolt.parragi@percona.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Tristan Partin <tristan@partin.io>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-07-08T15:33:29Z
Lists: pgsql-hackers
Attachments
- 02-docker-local.toml (application/octet-stream)
- 01-simple-production.toml (application/octet-stream)
- 4-enterprise-per-tenant.toml (application/octet-stream)
- 03-enterprise-multitenant.toml (application/octet-stream)
On Tue, Jul 7, 2026 at 6:17 PM Tristan Partin <tristan@partin.io> wrote: > I think the best option other than TOML is JSON5. I agree, my first prototype before TOML was JSON5. On Tue, Jul 7, 2026 at 10:21 PM Andrew Dunstan <andrew@dunslane.net> wrote: > Having implemented two (!) JSON parsers for PostgreSQL, as well as recently a json schema validator extension [1], I have some skin in this game. > I am really not a fan of implementing more and more little languages inside Postgres. Doing so will incur a non-zero maintenance burden. Mainly for this reason, because if we add JSON5 support to the parser that's already in postgres, we don't have to worry about adding another library. I focused on TOML in my email because I think that's still a better configuration format than JSON5. However, we could use JSON or another format, as long as it's a well-defined, common format, it will be a big improvement. My initial implementation used JSON/JSON5, and I also still have that patchset locally, which used a similar JSON structure. I only started prototyping with TOML after the initial feedback I got during pgconfdev that most people would prefer using that. On Tue, Jul 7, 2026 at 10:48 PM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > I'd be most interested in a mockup of the "final state" you have in > mind. That'd help highlight any need for homegrown syntax. (While > postgresql.conf may be declared out-of-scope, it's hard to imagine > we'd take steps towards an alternate format without some idea of what > the central server config is going to look like in the end.) I intentionally left my initial email somewhat vague about the details, and I didn't include the entire patchset implementing everything for the same reason: to keep the focus on generic questions like: * do we agree on working towards another configuration format? * if yes, what requirements do we have for it? * what exact issues do we want to solve, and what to leave as non-goals? I also understand your point, so I attached a few examples now, assuming a full implementation, including the toml support for postgresql.conf: 1. A very simple single file production configuration 2. A development docker image where the container has a built in configuration and users can specify an override configuration 3. A multi-tenant setup with the traditional hba/hosts/ident split 4. The same multi-tenant setup, but here the split is per tenant instead: one file for global configuration, and another 2 for the 2 tenants I want to note that for these examples: * We can replicate the same or similar structure easily in json/toml/others * For now this format is mostly based on my preferences with some feedback from others. I plan to talk about it to many more people and ask for feedback, so please treat this as a conversation starter, not a concrete suggestion * I am unsure about using the array syntax for hba rules, but so far I like it better than the alternative ideas I tried