MIME-Version: 1.0
References: 
 <CAN4CZFNXdKL4eb_GwT_h-vUuUV+CbPCk_8-+S3kV8iFmNmUw7A@mail.gmail.com>
 <DJSICZEWRJBC.XT5U5929XT0N@partin.io>
In-Reply-To: <DJSICZEWRJBC.XT5U5929XT0N@partin.io>
From: Andrew Dunstan <andrew@dunslane.net>
Date: Tue, 7 Jul 2026 17:21:18 -0400
Message-ID: 
 <CAD5tBc+ki9ynMuFRkFCCXVtyOO7HaEU7EEdGKA1LWgofNgdNOQ@mail.gmail.com>
Subject: Re: Proposal: new file format for hba/ident/hosts configuration?
To: Tristan Partin <tristan@partin.io>
Cc: Zsolt Parragi <zsolt.parragi@percona.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000006ca3a406560bf944"
Archived-At: 
 <https://www.postgresql.org/message-id/CAD5tBc%2Bki9ynMuFRkFCCXVtyOO7HaEU7EEdGKA1LWgofNgdNOQ%40mail.gmail.com>
Precedence: bulk

--0000000000006ca3a406560bf944
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 7, 2026 at 1:17=E2=80=AFPM Tristan Partin <tristan@partin.io> w=
rote:

> 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.

cheers

andrew


[1]  https://github.com/adunstan/json_schema_validate

--0000000000006ca3a406560bf944
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 7, =
2026 at 1:17=E2=80=AFPM Tristan Partin &lt;<a href=3D"mailto:tristan@partin=
.io">tristan@partin.io</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">On Tue Jul 7, 2026 at 12:00 PM CDT, Zsolt Parragi wro=
te:<br>
&gt; Hello hackers,<br>
&gt;<br>
&gt; [...]<br>
&gt;<br>
&gt; Is this a good idea in general? What does everyone think about the<br>
&gt; current configuration style? Is it good enough, or should we try to<br=
>
&gt; change it?<br>
<br>
I do not like it. I have created some VSCode extensions to help with <br>
syntax highlighting, but I would enjoy deprecating those.<br>
<br>
&gt; Moving on to more specific design questions, let&#39;s focus on the fi=
rst point:<br>
&gt;<br>
&gt; Common, non-vendor-specific configuration formats are INI, XML, JSON,<=
br>
&gt; YAML, and TOML.<br>
&gt;<br>
&gt; INI/conf is way too simple, and also not really a single standard, as<=
br>
&gt; there are many different implementations. XML isn&#39;t that popular<b=
r>
&gt; anymore.<br>
<br>
Agree.<br>
<br>
&gt; That leaves JSON/YAML/TOML. These all share one new requirement<br>
&gt; compared to the current PostgreSQL config infrastructure, valid UTF-8,=
<br>
&gt; but I don&#39;t think that could cause any practical problems.<br>
<br>
I think you have settled on 3 good options here. All of them support <br>
JSON Schema[0], which is super useful in validating files.<br>
<br>
&gt; YAML is complex, and has many unintuitive features. While it is quite<=
br>
&gt; common, I don&#39;t think we would want to include a full YAML parser =
in<br>
&gt; PostgreSQL, or try to write our own. We could try a limited YAML<br>
&gt; format, dropping some complex/unsafe features, but that would be as<br=
>
&gt; unintuitive as the current configuration formats, and could result in<=
br>
&gt; compatibility issues with existing YAML tooling.<br>
<br>
Completely agree.<br>
<br>
&gt; My initial choice for prototyping was JSON, and I ended up creating a<=
br>
&gt; few prototypes for pg_hba with it. At first I liked it, but the more I=
<br>
&gt; worked with it, the more I felt the JSON boilerplate hurt readability.=
<br>
&gt; It&#39;s still a fine machine format, but I don&#39;t think it&#39;s a=
 win for<br>
&gt; humans editing config files by hand. Its obvious advantage is that we<=
br>
&gt; already have a JSON parser in the code, and we could extend that to<br=
>
&gt; handle the more human-friendly JSONC/JSON5 variants.<br>
<br>
Agree.<br>
<br>
&gt; During <a href=3D"http://pgconf.dev" rel=3D"noreferrer" target=3D"_bla=
nk">pgconf.dev</a> several people mentioned TOML when I talked about<br>
&gt; the idea. Initially I dismissed it for mostly the same reason as<br>
&gt; INI/conf, as I thought it was too simple. But when I decided to try<br=
>
&gt; it, I actually liked it more than my JSON tests. It has a precise<br>
&gt; specification and many libraries, so it is both easy to parse and<br>
&gt; read.<br>
&gt;<br>
&gt; I&#39;d like to focus on this now, on what a specific TOML configurati=
on<br>
&gt; could look like. (I am not saying it has to be TOML, it is just the<br=
>
&gt; best option I&#39;ve found so far, but if you have a better suggestion=
,<br>
&gt; please share!)<br>
<br>
I like TOML, and it is quite popular. Another option is KDL: <br>
<a href=3D"https://kdl.dev/" rel=3D"noreferrer" target=3D"_blank">https://k=
dl.dev/</a>. Not saying that I think it should be used; only <br>
mentioning it to give other options.<br>
<br>
I think the best option other than TOML is JSON5.<br>
<br>
&gt; [...]<br>
<br>
[0]: <a href=3D"https://json-schema.org/" rel=3D"noreferrer" target=3D"_bla=
nk">https://json-schema.org/</a><br>
<br><br></blockquote><div><br></div><div>Having implemented two (!) JSON pa=
rsers for PostgreSQL, as well as recently a json schema validator extension=
 [1], I have some skin in this game.=C2=A0</div><div>I am really not a fan =
of implementing more and more little languages inside Postgres. Doing so wi=
ll incur a non-zero maintenance burden.</div><div><br></div><div>cheers</di=
v><div><br></div><div>andrew</div><div><br></div><div><br></div><div>[1]=C2=
=A0=C2=A0<a href=3D"https://github.com/adunstan/json_schema_validate">https=
://github.com/adunstan/json_schema_validate</a></div></div></div>

--0000000000006ca3a406560bf944--