> I've had a few thoughts about this. I tend to lean towards JSON, in part > because we already have it within Postgres. But the following applies to > whatever syntax is adopted.
As most answers seem to prefer json(5), I attached json5 versions of
my previous toml mockups. The structure is the same, I only changed
the representation of the include directives a bit.
> Rather than having specific config files for different topics, which makes
> sense if each is pretty close to just being essentially a database table
> with rows and columns rather than a nested structure, could we have a
> single config file that does everything?
That's part of my proposal, see 01 or 02. But in my initial email
specified this as a long-term goal, I think it is also a valid option
to rework only hba/hosts/ident and leave postgresql.conf and complete
unification as a next step.
We could also do a non-traditional split, that's my 04 example:
instead of postgresql-hba-ident-hosts, we have
postgresql-tenant1-tenant2.
With toml, including an entire file into a specific table is a tricky
and possibly confusing, so in that mockup/prototype, I defined include
as global-only.
There's a special include table, and all files mentioned there are
globally merged together with the main file. But other than this
limitation, includes are recursive.
This can possible be more generic in json if we want to allow it, as
that has a more visible nested structure.
In that prototype, I used the following logic:
* Every json5 file has to be an object at the top level
* { foo: { include: "bar.json5", "x": "y" } } means that we load
bar.json5 and merge it with the "foo" object.
I didn't use this in the mockups, but I think it is more intuitive in
json than in toml.
> Then all that is needed to keep using the existing files is to have a
> skeleton new-format file that essentially says "import legacy HBA from
> pg_hba.conf", "import legacy user name mappings from pg_ident.conf" and
> "import legacy GUC from postgresql.conf".
That is certainly an interesting idea, I like that it would make the
new format more visible, as a new style file would be always there. On
the other hand I worry that it wouldn't be this easy, unless the new
format is a trivial 1-1 mapping of the old files with a different
syntax, like my current mockups. And in that case, it can restrict us
how we can modify the new format while the old option still available.
03-enterprise-multitenant.json5
Description: Binary data
04-enterprise-per-tenant.json5
Description: Binary data
01-simple-production.json5
Description: Binary data
02-docker-local.json5
Description: Binary data
