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

From: "Tristan Partin" <tristan(at)partin(dot)io>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Zsolt Parragi" <zsolt(dot)parragi(at)percona(dot)com>
Cc: "Jacob Champion" <jacob(dot)champion(at)enterprisedb(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: new file format for hba/ident/hosts configuration?
Date: 2026-07-14 22:03:21
Message-ID: DJYMTU0CKKBE.KRG5EMVMV4BB@partin.io
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu Jul 9, 2026 at 12:16 PM UTC, Andrew Dunstan wrote:
> On Wed, Jul 8, 2026 at 11:33 AM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
> wrote:
>
>> On Tue, Jul 7, 2026 at 6:17 PM Tristan Partin <tristan(at)partin(dot)io> wrote:
>> > I think the best option other than TOML is JSON5.
>>
>> I agree, my first prototype before TOML was JSON5.
>>
>> On Tue, Jul 7, 2026 at 10:21 PM Andrew Dunstan <andrew(at)dunslane(dot)net>
>> wrote:
>> > 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.
>>
>> Mainly for this reason, because if we add JSON5 support to the parser
>> that's already in postgres, we don't have to worry about adding
>> another library.
>>
>> I focused on TOML in my email because I think that's still a better
>> configuration format than JSON5. However, we could use JSON or another
>> format, as long as it's a well-defined, common format, it will be a
>> big improvement.
>>
>>
>>
> Just for kicks I asked my new best friend (<weg>) to allow for json5 on the
> RD parser. The actual parser changes are minimal. Most of the changes are
> in the lexer. I didn't implement it for the incremental parser, and I
> skipped the new numeric formats.

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 am basically done with a JSONC patch that has support for both the
recursive-descent parser and the incremental parser. I need to polish it
up a bit before I send it, and it builds on top of some of my other work
refactoring json_lex()[0].

Do we want to support JSONC/JSON5 in the incremental parser? My
inclination is yes so the parsers are consistent in what they support.

[0]: https://www.postgresql.org/message-id/DJXSBQVKCQU2.SIQVXEH2P0AM@partin.io

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-07-14 22:13:30 Re: Report oldest xmin source when autovacuum cannot remove tuples
Previous Message Andrew Dunstan 2026-07-14 21:23:40 meson: avoid PATH bloat from NLS .mo targets in tmp_install test setup