On Wed, Oct 14, 2015 at 6:30 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-10-14 01:54:46 +0300, Amir Rohan wrote:
>> Andres, please see upthread for quite a bit on what it doesn't do, and
>> why having it in the server is both an advantages and a shortcoming.
>
> As far as I have skimmed the thread it's only talking about shortcoming
> in case it requires a running server. Which -C doesn't.
>
> I don't think there's any fundamental difference between some external
> binary parsing & validating the config file and the postgres binary
> doing it. There *is* the question of the utility being able to to
> process options from multiple major releases, but I don't think that's a
> particularly worthwhile goal here.
But if you want to write something like pgtune - in addition to that
particular thing, EDB has several tools that do this kind of stuff -
then it's either got to be part of the server, which is not viable
unless you're (ahem) prepared to maintain a fork of the server in
perpetuity - or it's got to be somewhere else, in which case you've
got to write your own lexer and parser for our config-file format.
Now fortunately that format isn't crazy complicated, but this wheel
has been reinvented multiple times, and will be again. Making it
possible for people to use ours rather than rolling their own would be
a good thing, IMHO.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
