public inbox for [email protected]  

help / color / mirror / Atom feed

From: Zsolt Parragi <[email protected]>
To: Tom Lane <[email protected]>
Cc: Tristan Partin <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Subject: Re: Proposal: new file format for hba/ident/hosts configuration?
Date: Wed, 8 Jul 2026 16:42:03 +0100
Message-ID: <CAN4CZFNxcxSqPREZN61tcpCF5jsfOH1A+-gmmetrirtGuM2JPQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAN4CZFNXdKL4eb_GwT_h-vUuUV+CbPCk_8-+S3kV8iFmNmUw7A@mail.gmail.com>
	<[email protected]>
	<CAD5tBc+ki9ynMuFRkFCCXVtyOO7HaEU7EEdGKA1LWgofNgdNOQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>

On Tue, Jul 7, 2026 at 10:58 PM Tom Lane <[email protected]> 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.

view thread (11+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Proposal: new file format for hba/ident/hosts configuration?
  In-Reply-To: <CAN4CZFNxcxSqPREZN61tcpCF5jsfOH1A+-gmmetrirtGuM2JPQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox