Thread

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

   Zsolt Parragi <zsolt.parragi@percona.com> — 2026-07-07T17:00:21Z

   Hello hackers,
   
   Currently the hba/ident/hosts configuration files follow similar, but
   subtly different, whitespace-separated formats. While this works,
   there are several problems with it:
   
   1. it is a PostgreSQL-specific format, without commonly available parsers.
   2. extensibility is limited, which becomes clearly visible in multiple
   discussions/patch proposals. Two recent examples are:
     2.1. the OAuth validators and hba[1]: validators often require extra
   fields, and while they can add GUCs, those are global. In a
   multi-tenant application, different hba lines might require different
   validator configuration. To properly support this use case, validators
   have to be able to extend the options in pg_hba.
     2.2. a recent discussion about adding alternative SSL keys, which
   also requires an extension of pg_hosts[2], and that's tricky to do in
   a readable way.
   3. we can include other files in them, or we can load options from
   separate files for hba, but we can't go the other direction: keeping
   everything (hba, ident, hosts) together in a single file.
   4. while they look the same, hba is order-sensitive, ident is
   order-independent in semantics (today's parser happens to walk
   top-down), and the new pg_hosts is explicitly unordered.
   
   I'd like to improve the above points by introducing a new
   configuration format, while also keeping the current format for
   backward compatibility. Backward compatibility would be limited to
   currently available features, as in the future, we can't guarantee
   that we can fit every new feature into the old formats in an
   easy-to-understand way. I would even say that we should implement new
   functionality only in the new formats.
   
   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?
   
   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.
   
   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.
   
   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.
   
   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.
   
   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 also attached a discussion-starter patchset that implements the
   described format for pg_hosts. As PostgreSQL doesn't currently include
   a TOML parser, it uses a vendored tomlc17 parser[3], not necessarily
   the final approach, but the easiest way to build a PoC that showcases
   the concept, since tomlc17 isn't packaged for most of our supported
   platforms. I also have similar patches for the other configuration
   files, but I'm intentionally including only one of them for
   simplicity.
   
   1. pg_ident
   
   Ident contains multiple maps, which map external usernames to internal
   usernames, possibly with regexes. Matching works on both fields, as we
   are looking for specific pairs. Currently ident parsing is ordered,
   but this is an implementation detail, not a functional requirement: we
   are only interested in whether a pair is present. If it is matched by
   multiple lines, it doesn't matter which line we select, as it's not
   user-visible, other than a log entry.
   
   Based on that, I think we can configure it simply in the following way:
   
   [ident]
   map1name = {
       "sysuser1" = "ppuser1",
       '/^(.*)@mydomain\.com$' = '\1',
   }
   map2name = {
       "sysuser1" = "ppuser1",
       "sysuser2" = "ppuser2",
   }
   
   This removes the ordering, since TOML tables are unordered, but it is
   simple, using the system username as a key and the PostgreSQL username
   as the value.
   
   In its current form, it is not extensible. I don't think we have to be
   concerned about that too much for ident, but if we ever need to allow
   additional values per mapping, we can always optionally allow the
   value to be a table like:
   
           "sysuser1" = { username = "ppuser1", other_param = "value",
   foo = "bar" },
   
   I also put everything under the "[ident]" table, which helps with the
   "possibly keeping everything in a single file" point.
   
   I also want to point out that in the above example map1name / map2name
   are inline tables, and if somebody prefers, this can also be written
   in the following way, which has the same meaning:
   
   [ident.map1name]
   sysuser1 = "ppuser1"
   '/^(.*)@mydomain\.com$' = '\1'
   
   [ident.map2name]
   "sysuser1" = "ppuser1"
   "sysuser2" = "ppuser2"
   
   2. pg_hosts
   
   Hosts is explicitly unordered. It contains hostnames, and every
   hostname has associated fields (certificate, key, ca, passphrase
   command, reload), which perfectly fits the "extensibility" version of
   ident I sketched above. Compared to ident it is only a single map, so
   we can store entries directly under the "[hosts]" table.
   
   We can either write:
   
   [hosts]
   "hostname1" = { ca = "...", key = "...", passphrase_command = "..." }
   "hostname2" = { ca = "...", key = "...", passphrase_command = "..." }
   
   Or again we can write this as:
   
   [hosts.hostname1]
   ca = "..."
   key = "..."
   passphrase_command = "..."
   
   [hosts.hostname2]
   ca = "..."
   key = "..."
   passphrase_command = "..."
   
   This format also clearly gives us extensibility. This is currently
   limited to SNI support, but "hosts" is a generic name, in case we ever
   want to add more properties.
   
   One idea worth considering is a "_defaults" (or similar)
   pseudo-hostname. For example, if all hostnames share the same CA, it
   saves repeating that everywhere.
   
   3. pg_hba
   
   This is by far the trickiest format of the three, mainly because of
   the options list at the end. Fortunately, we can simplify that part
   with TOML, since we can treat each line as a table.
   
   The main issue compared to the previous two is that we have to keep
   pg_hba ordered, which means we have to use an array for the lines.
   
   We also need some kind of support for defaults, similar to what I
   proposed for hosts, or something even more powerful, to somewhat
   replicate and improve what the hba configuration can already do with
   the @include syntax.
   
   [hba]
       _defaults = { host = "localhost", ssl = "required", transport = "tcp" }
       remote = { host = ["*"] }
   
   [[hba.rules]]
       based_on = "remote" # or alternatively, can be an array to include
   multiple: [ "remote", "another" ]
       user = "foo"
       auth_method = "oauth"
       issuer = "..."
       # ...
   
   [[hba.rules]]
   # next rule
   
   In the above example I already used the special TOML syntax for arrays
   of tables, but of course doing this completely inline is also
   possible.
   
   The idea here is that we can specify absolute defaults using the
   "_defaults" as before (using _ for consistency with hosts), and also
   include other tables to provide more base settings for a specific
   rule, using a special based_on property. The value(s) for based_on
   reference tables inside hba, e.g. including "foo" means including
   "hba.foo".
   
   With based_on, we can also cover part of what the @include syntax does
   today: for example, we can define a database array in a separate table
   and reference it from a rule. Based on what I've explained so far,
   though, this only works within the same file.
   
   What's missing from the above specification is including external
   files: TOML has no official support for this, and the generic
   suggestion in multiple discussions about it is to "roll your own
   extension". This is common for most standard configuration file
   formats, which generally leave this part up to the applications.
   
   Adding an include mechanism has the disadvantage that standard parsers
   won't be able to use it. But it's an optional feature, and we could
   also provide a helper script that generates a "unified" view of an
   include hierarchy, which then can be used by standard TOML parsers.
   
   As for the syntax, I think we should simply reuse the existing
   include_dir / include_if_exists / include directives, as present in
   postgresql.conf, with the additional requirement that we always treat
   include directives as global/positional. It's a "preprocessor
   directive" similar to #include in C, in that it just concatenates
   files together. I think this has many advantages:
   
   1. it keeps the syntax valid TOML, so any TOML library can parse it
   (includes found in any table = treat it as global scope, also load
   those files, calculate the union)
   2. postgresql.conf is already close to TOML. Above I said that it
   would be good if we could unify the 3 whitespace-separated
   configuration files into one, but with minimal additional effort we
   can do more. Since everything for ident/hosts/hba lives in additional
   tables, all we have to say is that postgresql.conf only cares about
   the global table and ignores everything else, and we can then store
   the whole configuration in a single file.
   
   Of course, postgresql.conf allows some syntax that isn't valid TOML,
   so it isn't a drop-in subset today, but converting a postgresql.conf
   to TOML wouldn't require much work. The main difference is that TOML
   doesn't allow unquoted strings, so values like "replica" or "128MB"
   need quotes around them.
   
   I want to make clear that postgresql.conf is not in the scope of this
   proposal. That's possible future work which I think is important to
   mention, but I want to keep the focus on ident/hosts/hba.
   
   I think the second point is especially useful for cloud/container
   deployments, or for tests/examples/tutorials. I am not a DBA, so I
   don't want to claim that I know all about PostgreSQL configuration,
   but my understanding is that most deployments have relatively simple
   configuration, where this option would help.
   
   What do you think about this in general? About using TOML? About the
   specific TOML format I suggested here?
   
   [1]: https://www.postgresql.org/message-id/CAN4CZFM3b8u5uNNNsY6XCya257u%2BDofms3su9f11iMCxvCacag%40mail.gmail.com
   [2]: https://www.postgresql.org/message-id/0cabf744-6d58-4bc4-817a-413c804cf61d%40redhat.com
   [3]: https://github.com/cktan/tomlc17
   

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

   Tristan Partin <tristan@partin.io> — 2026-07-07T17:17:16Z

   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/
   
   -- 
   Tristan Partin
   PostgreSQL Contributors Team
   AWS (https://aws.amazon.com)
   
   
   
   

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

   Andrew Dunstan <andrew@dunslane.net> — 2026-07-07T21:21:18Z

   On Tue, Jul 7, 2026 at 1:17 PM Tristan Partin <tristan@partin.io> 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.
   
   cheers
   
   andrew
   
   
   [1]  https://github.com/adunstan/json_schema_validate
   

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

   Tristan Partin <tristan@partin.io> — 2026-07-07T21:44:46Z

   On Tue Jul 7, 2026 at 9:21 PM UTC, Andrew Dunstan wrote:
   > On Tue, Jul 7, 2026 at 1:17 PM Tristan Partin <tristan@partin.io> 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)
   
   
   
   

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

   Jacob Champion <jacob.champion@enterprisedb.com> — 2026-07-07T21:48:16Z

   On Tue, Jul 7, 2026 at 2:21 PM Andrew Dunstan <andrew@dunslane.net> wrote:
   > I am really not a fan of implementing more and more little languages inside Postgres. Doing so will incur a non-zero maintenance burden.
   
   Sure, but the status quo has its own self-compounding maintenance
   burden, in which we'll either need to keep implementing little
   languages (as with pg_hosts.conf) or else finally decide to refactor.
   
   On Tue, Jul 7, 2026 at 10:00 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
   > What do you think about this in general? About using TOML? About the
   > specific TOML format I suggested here?
   
   FWIW, I was recently looking at TOML for libpqrc [1]. Of the
   non-custom options you've presented, I prefer its feature set, so I
   think it's at least an interesting alternative to explore. I was
   especially interested in the pyproject.toml conventions, where
   different parts of the ecosystem all coexist in the same configuration
   space -- that might be important for letting libpq and other drivers
   move in parallel.
   
   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.)
   
   Thanks for working on this!
   
   --Jacob
   
   [1] https://postgr.es/m/CAOYmi%2BmhiTPmNxy9JDKh%2BpahDxz2OoxAf%3D-jq%2BG%2BYUkHHqAGUA%40mail.gmail.com
   
   
   
   

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

   Tom Lane <tgl@sss.pgh.pa.us> — 2026-07-07T21:58:30Z

   I'm noticing a distinct lack of focus on what would be the benefits
   to *end users* of Postgres.  I can't see proceeding with a project
   like this unless there are strong benefits that would entice people
   to convert their configuration files of their own accord [*].
   And really I don't think any of the benefits enumerated at the top of
   the thread are going to sell very many users on doing that.  It's
   not their problem if we're having issues shoehorning new features
   into the existing format.
   
   			regards, tom lane
   
   [*] If we try to force it, even by such weak means as not implementing
   new features in the old format, we will have mobs of villagers with
   pitchforks on our doorsteps.
   
   
   
   

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

   Jacob Champion <jacob.champion@enterprisedb.com> — 2026-07-07T23:08:04Z

   On Tue, Jul 7, 2026 at 2:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
   > It's
   > not their problem if we're having issues shoehorning new features
   > into the existing format.
   
   (It is, though. Users like new features, and I have yet to meet a user
   who's happy that we don't implement reasonable improvements because of
   choices made pre-21st-century. The config format has gotten in the way
   of recent development, and it's starting to force a bunch of
   unpleasant compromises.)
   
   --Jacob
   
   
   
   

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

   Zsolt Parragi <zsolt.parragi@percona.com> — 2026-07-08T15:33:29Z

   On Tue, Jul 7, 2026 at 6:17 PM Tristan Partin <tristan@partin.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@dunslane.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.champion@enterprisedb.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
   

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

   Zsolt Parragi <zsolt.parragi@percona.com> — 2026-07-08T15:42:03Z

   On Tue, Jul 7, 2026 at 10:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
   
   > I'm noticing a distinct lack of focus on what would be the benefits
   > to *end users* of Postgres.
   
   The biggest benefit is that postgres would support a common
   configuration format that users don't have to learn. Most software
   today uses either toml, json or yaml for complex configuration.
   Existing installations / users is one thing, new installation / new
   users is another. Instead of somebody having to learn 4 slightly
   different configuration file formats specific to postgres, we could
   document the format with a single sentence: "It's <X>", and everyone
   would know what that means.
   
   I also mentioned tooling, and Tristan also mentioned transformation
   and json schema: there are many existing libraries and tools dealing
   with these formats, no matter which one we choose. Editors,
   validators, syntax highlighting, converters, ... If we choose toml,
   people can still use json and convert it, and the same would be true
   in the other direction.
   
   And there's also readability: the issues with implementing the two
   examples I mentioned aren't the only problem (one was even implemented
   and committed), the main issue is the user experience.
   
   In pg_hba, we already have a way too long "options" column at the end,
   where we store most of the details about external auth providers. If
   an editor doesn't add line breaks, a significant part of the
   configuration is invisible without scrolling right. If it adds them,
   that breaks the look of the tabulated format. If we use the @include
   syntax, we move them into a separate file and again we can't see
   everything in a clear way on a single screen.
   
   The pg_hosts example is similar, I thought about 5 different ways we
   could add it to pg_hosts that would technically work, so just
   implementing it isn't an issue. The problem is that from a
   usability/readability viewpoint I would only give maybe a 6/10 to the
   best one, or even less.