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

On Tue Jul 7, 2026 at 9:21 PM UTC, Andrew Dunstan wrote:
> On Tue, Jul 7, 2026 at 1:17 PM Tristan Partin <tristan(at)partin(dot)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 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.
>
> [1] https://github.com/adunstan/json_schema_validate

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

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

Additionally, I would add that maintaining our own custom format comes
with its own challenges and warts as well. See /no_sni/, which I learned
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/

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