* Amit Kapila (amit.kapila@huawei.com) wrote:
> > This is an internal-to-PG data file and we should really implement it
> > in whichever way makes the most sense for us. My general feeling is
> > that one file is simpler and sufficient for the postgresql.conf-like
> > parameters,
>
> Sure, I also feel the same that if it can be addressed with single file,
> then lets do that way only.
We need to settle on one choice and then implement it, yes. It
certainly doesn't make any sense to have two different ways to deal with
an internal-to-PG data structure. Of course, that might argue for
making this file actually *be* like pg_authid is today; has that been
considered? I'm guessing it's not practical because the point where we
need to read the config is before certain things have been set up to
allow reading from heap files, but it seems like something which should
at least be considered. If we can make it work, then that may also
solve the pg_hba/pg_ident issue, which is about a bazillion times more
interesting than the mostly set-and-forget postgresql.conf settings.
Perhaps having the file be a heap file instead of anything a sysadmin
can be asked to go hack would also make it more clear that this is an
internal PG file which is to be managed only through PG and stop all
this arguing about how "oh, they can just fix it by twiddling things in
$PGDATA" is considered by some to be an acceptable solution. Heck, it'd
also keep the number of files down while allowing more fine-grained
modifications and writes (iow, we wouldn't have to rewrite the whole
file every time..).
Thanks,
Stephen
