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

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