Feedback-ID: idd01497b:Fastmail
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 07 Jul 2026 17:17:16 +0000
Message-Id: <DJSICZEWRJBC.XT5U5929XT0N@partin.io>
Cc: "PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>
Subject: Re: Proposal: new file format for hba/ident/hosts configuration?
To: "Zsolt Parragi" <zsolt.parragi@percona.com>
From: "Tristan Partin" <tristan@partin.io>
References: 
 <CAN4CZFNXdKL4eb_GwT_h-vUuUV+CbPCk_8-+S3kV8iFmNmUw7A@mail.gmail.com>
In-Reply-To: 
 <CAN4CZFNXdKL4eb_GwT_h-vUuUV+CbPCk_8-+S3kV8iFmNmUw7A@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/DJSICZEWRJBC.XT5U5929XT0N%40partin.io>
Precedence: bulk

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=20
syntax highlighting, but I would enjoy deprecating those.

> Moving on to more specific design questions, let's focus on the first poi=
nt:
>
> 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=20
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:=20
https://kdl.dev/. Not saying that I think it should be used; only=20
mentioning it to give other options.

I think the best option other than TOML is JSON5.

> [...]

[0]: https://json-schema.org/

--=20
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)