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 21:44:46 +0000
Message-Id: <DJSO1SIMD260.1THBEIYVZ034A@partin.io>
Cc: "Zsolt Parragi" <zsolt.parragi@percona.com>, "PostgreSQL Hackers"
 <pgsql-hackers@lists.postgresql.org>, "Daniel Gustafsson" <daniel@yesql.se>
Subject: Re: Proposal: new file format for hba/ident/hosts configuration?
To: "Andrew Dunstan" <andrew@dunslane.net>
From: "Tristan Partin" <tristan@partin.io>
References: 
 <CAN4CZFNXdKL4eb_GwT_h-vUuUV+CbPCk_8-+S3kV8iFmNmUw7A@mail.gmail.com>
 <DJSICZEWRJBC.XT5U5929XT0N@partin.io>
 <CAD5tBc+ki9ynMuFRkFCCXVtyOO7HaEU7EEdGKA1LWgofNgdNOQ@mail.gmail.com>
In-Reply-To: 
 <CAD5tBc+ki9ynMuFRkFCCXVtyOO7HaEU7EEdGKA1LWgofNgdNOQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/DJSO1SIMD260.1THBEIYVZ034A%40partin.io>
Precedence: bulk

On Tue Jul 7, 2026 at 9:21 PM UTC, Andrew Dunstan wrote:
> On Tue, Jul 7, 2026 at 1:17=E2=80=AFPM Tristan Partin <tristan@partin.io>=
 wrote:
>
>> 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
>> syntax highlighting, but I would enjoy deprecating those.
>>
>> > Moving on to more specific design questions, let's focus on the first
>> point:
>> >
>> > 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
>> 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:
>> https://kdl.dev/. Not saying that I think it should be used; only
>> mentioning it to give other options.
>>
>> I think the best option other than TOML is JSON5.
>>
>> > [...]
>>
>> [0]: https://json-schema.org/
>>
>>
>>
> Having implemented two (!) JSON parsers for PostgreSQL, as well as recent=
ly
> 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 insi=
de
> Postgres. Doing so will incur a non-zero maintenance burden.
>
> [1]  https://github.com/adunstan/json_schema_validate

Yes, thanks for stating that. Do you view the file format as a problem=20
at all? In Zsolt's proposal, he vendored tomlc17. Do you have=20
a suggestion for an alternative approach? Is depending on tomlc17 and=20
not vendoring an option? Would that assuage your maintenance concerns at=20
all? Do we have requirements for when Postgres can take on another=20
dependency? Daniel Gustaffson brought the file format up in his=20
"Serverside SNI in PostgreSQL 19"[0] talk at PGConf.dev.

One thing that hasn't been mentioned is that higher level configuration=20
languages can "compile" to JSON. For instance, HCL[1] (HashiCorp=20
Configuration Language) and Pkl[2] have that ability. If we settled on=20
JSON, then users could use these types of languages for higher level=20
writing of configs.

Additionally, I would add that maintaining our own custom format comes=20
with its own challenges and warts as well. See /no_sni/, which I learned=20
about at Daniel's talk.

[0]: https://2026.pgconf.dev/session/757
[1]: https://github.com/hashicorp/hcl#information-model-and-syntax
[2]: https://pkl-lang.org/

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