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

On Tue, Jul 7, 2026 at 10:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I'm noticing a distinct lack of focus on what would be the benefits
> to *end users* of Postgres.

The biggest benefit is that postgres would support a common
configuration format that users don't have to learn. Most software
today uses either toml, json or yaml for complex configuration.
Existing installations / users is one thing, new installation / new
users is another. Instead of somebody having to learn 4 slightly
different configuration file formats specific to postgres, we could
document the format with a single sentence: "It's <X>", and everyone
would know what that means.

I also mentioned tooling, and Tristan also mentioned transformation
and json schema: there are many existing libraries and tools dealing
with these formats, no matter which one we choose. Editors,
validators, syntax highlighting, converters, ... If we choose toml,
people can still use json and convert it, and the same would be true
in the other direction.

And there's also readability: the issues with implementing the two
examples I mentioned aren't the only problem (one was even implemented
and committed), the main issue is the user experience.

In pg_hba, we already have a way too long "options" column at the end,
where we store most of the details about external auth providers. If
an editor doesn't add line breaks, a significant part of the
configuration is invisible without scrolling right. If it adds them,
that breaks the look of the tabulated format. If we use the @include
syntax, we move them into a separate file and again we can't see
everything in a clear way on a single screen.

The pg_hosts example is similar, I thought about 5 different ways we
could add it to pg_hosts that would technically work, so just
implementing it isn't an issue. The problem is that from a
usability/readability viewpoint I would only give maybe a 6/10 to the
best one, or even less.