Re: Proposal: new file format for hba/ident/hosts configuration?
Tristan Partin <tristan@partin.io>
From: "Tristan Partin" <tristan@partin.io>
To: "Zsolt Parragi" <zsolt.parragi@percona.com>
Cc: "PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>
Date: 2026-07-07T17:17:16Z
Lists: pgsql-hackers
On Tue Jul 7, 2026 at 12:00 PM CDT, Zsolt Parragi wrote: > Hello hackers, > > [...] > > Is this a good idea in general? What does everyone think about the > current configuration style? Is it good enough, or should we try to > change it? I do not like it. I have created some VSCode extensions to help with syntax highlighting, but I would enjoy deprecating those. > Moving on to more specific design questions, let's focus on the first point: > > Common, non-vendor-specific configuration formats are INI, XML, JSON, > YAML, and TOML. > > INI/conf is way too simple, and also not really a single standard, as > there are many different implementations. XML isn't that popular > anymore. Agree. > That leaves JSON/YAML/TOML. These all share one new requirement > compared to the current PostgreSQL config infrastructure, valid UTF-8, > but I don't think that could cause any practical problems. I think you have settled on 3 good options here. All of them support JSON Schema[0], which is super useful in validating files. > YAML is complex, and has many unintuitive features. While it is quite > common, I don't think we would want to include a full YAML parser in > PostgreSQL, or try to write our own. We could try a limited YAML > format, dropping some complex/unsafe features, but that would be as > unintuitive as the current configuration formats, and could result in > compatibility issues with existing YAML tooling. Completely agree. > My initial choice for prototyping was JSON, and I ended up creating a > few prototypes for pg_hba with it. At first I liked it, but the more I > worked with it, the more I felt the JSON boilerplate hurt readability. > It's still a fine machine format, but I don't think it's a win for > humans editing config files by hand. Its obvious advantage is that we > already have a JSON parser in the code, and we could extend that to > handle the more human-friendly JSONC/JSON5 variants. Agree. > During pgconf.dev several people mentioned TOML when I talked about > the idea. Initially I dismissed it for mostly the same reason as > INI/conf, as I thought it was too simple. But when I decided to try > it, I actually liked it more than my JSON tests. It has a precise > specification and many libraries, so it is both easy to parse and > read. > > I'd like to focus on this now, on what a specific TOML configuration > could look like. (I am not saying it has to be TOML, it is just the > best option I've found so far, but if you have a better suggestion, > please share!) I like TOML, and it is quite popular. Another option is KDL: https://kdl.dev/. Not saying that I think it should be used; only mentioning it to give other options. I think the best option other than TOML is JSON5. > [...] [0]: https://json-schema.org/ -- Tristan Partin PostgreSQL Contributors Team AWS (https://aws.amazon.com)