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

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tristan Partin <tristan(at)partin(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: new file format for hba/ident/hosts configuration?
Date: 2026-07-08 15:33:29
Message-ID: CAN4CZFPQiNvfX2k35zYi9eZ7-kC5vEeQtiM_nOce3MNpK4Ai_w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 7, 2026 at 6:17 PM Tristan Partin <tristan(at)partin(dot)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(at)dunslane(dot)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(dot)champion(at)enterprisedb(dot)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

Attachment Content-Type Size
02-docker-local.toml application/octet-stream 1.0 KB
01-simple-production.toml application/octet-stream 1.2 KB
4-enterprise-per-tenant.toml application/octet-stream 2.2 KB
03-enterprise-multitenant.toml application/octet-stream 2.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikita Malakhov 2026-07-08 15:35:00 Re: SQL/JSON json_table plan clause
Previous Message Andrey Rachitskiy 2026-07-08 15:26:48 Re: pg19b1: TRAP: failed Assert("pgstat_bktype_io_stats_valid(bktype_shstats, MyBackendType)")