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

On Tue, Jul 14, 2026 at 7:27 PM Tristan Partin <tristan(at)partin(dot)io> wrote:

> On Tue Jul 14, 2026 at 11:18 PM UTC, Zsolt Parragi wrote:
> >> What are your thoughts on first starting with support for JSONC? It has
> >> no implications other than comments (single-line and multi-line) and
> >> trailing commas. We could collaborate and commit that, and then
> >> subsequently work on JSON5 support. It should enable the JSON5 support
> >> patches to be even smaller than what you posted already.
> >
> > I also sent my patchset[1] for JSONC/JSON5. I wanted to organize it
> > into smaller patches and stress test it before sharing, but I think
> > it's in a good enough shape now.
> > My logic was similar: the first patch in the series is the JSONC
> > support, as that's a feature usable on its own.
>
> Awesome. I will review and see how they compare against my changes!
>
> >> Do we want to support JSONC/JSON5 in the incremental parser? My
> >> inclination is yes so the parsers are consistent in what they support.
> >
> > I included it for completeness, but the incremental parser has no real
> > user other than the tests, and it's complex. A patch without that
> > would be significantly smaller. Most (nearly all) of the corner case
> > issues I identified while testing the patch were also in that.
>
> I was able to get a patch for the incremental parser to support comments
> in:
>
> 1 file changed, 272 insertions(+), 41 deletions(-)
>
> A patch to the incremental parser to support trailing commas is even
> smaller:
>
> 1 file changed, 87 insertions(+), 1 deletions(-)
>
> These stats don't include the additional tests.
>
> > [1]:
> https://www.postgresql.org/message-id/CAN4CZFP5dvO4sij414YYG%2B4Hghf3M5m2oPiyR_vNgRj3vhQ_0Q%40mail.gmail.com
>
>
>

I'm inclined not to support the incremental parser. From a pure grammar POV
it would be doable - you would just need a new parsing table. But I suspect
the added complexity for the lexer would be considerable. It's already
fairly complex, so that bothers me. Also, what's the use case? The point of
the incremental parser is to support handling huge documents like backup
manifests. But that's not the use case for JSON5. At least for a first go
round I would stick with supporting the RD parser only. Then you can ignore
things like partial tokens,

It might be worth talking about the data representation of a JSON5 datum.
One of my first experiments with claude code was the creation of an
extension to support YAML. See <https://github.com/adunstan/pgyaml>. One
possibly controversial decision I made was to store the YAML in two formats
- original text plus the data as jsonb. That costs you some in storage but
makes up for it in allowing you to use the equivalent of jsonb ops, and
jsonpath on the data efficiently while being able to get back the original
text as well. This could be reasonable for small documents such as
configuration settings, which is the main use case I see for YAML (and
JSON5). (It also provides methods you convert the YAML to pure jsonb)

cheers

andrew