Re: Proposal: new file format for hba/ident/hosts configuration?

On Tue, Jul 7, 2026 at 1:17 PM Tristan Partin <tristan@partin.io> wrote:

> 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/
>
>
>
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.

cheers

andrew


[1]  https://github.com/adunstan/json_schema_validate