| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Tristan Partin <tristan(at)partin(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Proposal: new file format for hba/ident/hosts configuration? |
| Date: | 2026-07-08 15:33:29 |
| Message-ID: | CAN4CZFPQiNvfX2k35zYi9eZ7-kC5vEeQtiM_nOce3MNpK4Ai_w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
My initial implementation used JSON/JSON5, and I also still have that
patchset locally, which used a similar JSON structure. I only started
prototyping with TOML after the initial feedback I got during
pgconfdev that most people would prefer using that.
On Tue, Jul 7, 2026 at 10:48 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> I'd be most interested in a mockup of the "final state" you have in
> mind. That'd help highlight any need for homegrown syntax. (While
> postgresql.conf may be declared out-of-scope, it's hard to imagine
> we'd take steps towards an alternate format without some idea of what
> the central server config is going to look like in the end.)
I intentionally left my initial email somewhat vague about the
details, and I didn't include the entire patchset implementing
everything for the same reason: to keep the focus on generic questions
like:
* do we agree on working towards another configuration format?
* if yes, what requirements do we have for it?
* what exact issues do we want to solve, and what to leave as non-goals?
I also understand your point, so I attached a few examples now,
assuming a full implementation, including the toml support for
postgresql.conf:
1. A very simple single file production configuration
2. A development docker image where the container has a built in
configuration and users can specify an override configuration
3. A multi-tenant setup with the traditional hba/hosts/ident split
4. The same multi-tenant setup, but here the split is per tenant
instead: one file for global configuration, and another 2 for the 2
tenants
I want to note that for these examples:
* We can replicate the same or similar structure easily in json/toml/others
* For now this format is mostly based on my preferences with some
feedback from others. I plan to talk about it to many more people and
ask for feedback, so please treat this as a conversation starter, not
a concrete suggestion
* I am unsure about using the array syntax for hba rules, but so far I
like it better than the alternative ideas I tried
| Attachment | Content-Type | Size |
|---|---|---|
| 02-docker-local.toml | application/octet-stream | 1.0 KB |
| 01-simple-production.toml | application/octet-stream | 1.2 KB |
| 4-enterprise-per-tenant.toml | application/octet-stream | 2.2 KB |
| 03-enterprise-multitenant.toml | application/octet-stream | 2.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikita Malakhov | 2026-07-08 15:35:00 | Re: SQL/JSON json_table plan clause |
| Previous Message | Andrey Rachitskiy | 2026-07-08 15:26:48 | Re: pg19b1: TRAP: failed Assert("pgstat_bktype_io_stats_valid(bktype_shstats, MyBackendType)") |