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

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(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-09 22:48:37
Message-ID: CAOYmi+nxQwwkmb5NEj_LUS6ZCstWqyM-Do3KbqdV9JW3YmwbWA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 8, 2026 at 8:33 AM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
> I focused on TOML in my email because I think that's still a better
> configuration format than JSON5.

(I agree)

> * 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?

Adding small pieces to this pile: I'm primarily motivated by authn/z,
and I'd like to be able to more intuitively attach parameters to
certain connection contexts. This is something that neither a flat
configuration, nor separated tabular configurations, have really
helped us with.

"Connections using SCRAM authentication should time out in X seconds
instead of the default." Or "this group of users should use the
following list of GUCs." The sample I used in [1] a long time ago was

Everyone has to use LDAP auth
With this server
And these TLS settings

Except admins
who additionally need client certificates
with this CA root

And Jacob
who isn't allowed in anymore

We don't handle these (perfectly reasonable IMO) cases very well, or
sometimes at all. I'm primarily used to servers in the web space
(httpd, nginx, caddy, haproxy) when it comes to this configuration
style, which I think I called "contexts with property bags" in that
other thread.

> * I am unsure about using the array syntax for hba rules, but so far I
> like it better than the alternative ideas I tried

FWIW I find that part of it pretty hard to read and understand, though
that should not in any way spike the general concept into the ground.

Thanks!
--Jacob

[1] https://postgr.es/m/0e0c038ab962c3f6dab00934fe5ae1ae115f44c0.camel%40vmware.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2026-07-09 23:05:04 Re: Include sequences in publications created by pg_createsubscriber
Previous Message Bryan Green 2026-07-09 22:07:15 Re: pg_dump: use threads for parallel workers on all platforms