public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tristan Partin <[email protected]>
To: Andrew Dunstan <[email protected]>
Cc: Zsolt Parragi <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Subject: Re: Proposal: new file format for hba/ident/hosts configuration?
Date: Tue, 07 Jul 2026 21:44:46 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAD5tBc+ki9ynMuFRkFCCXVtyOO7HaEU7EEdGKA1LWgofNgdNOQ@mail.gmail.com>
References: <CAN4CZFNXdKL4eb_GwT_h-vUuUV+CbPCk_8-+S3kV8iFmNmUw7A@mail.gmail.com>
<[email protected]>
<CAD5tBc+ki9ynMuFRkFCCXVtyOO7HaEU7EEdGKA1LWgofNgdNOQ@mail.gmail.com>
On Tue Jul 7, 2026 at 9:21 PM UTC, Andrew Dunstan wrote:
> On Tue, Jul 7, 2026 at 1:17 PM Tristan Partin <[email protected]> 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)
view thread (11+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Proposal: new file format for hba/ident/hosts configuration?
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox