Greg Smith <gsm...@gregsmith.com> writes:
> The sketched out design I have for a contrib/pgtune in C presumes that I'd
> start by refactoring the relevant bits from initdb into a library for both
> programs to use. But the initdb code doesn't care about preserving
> existing values when making changes to them; it just throws in its new
> settings and moves along. So what's there already only handles about half
> the annoying parts most people would expect a tuning tool that reads the
> existing file and operates on it to do.
> Also, I wouldn't be surprised to find that it chokes on some real-world
> postgresql.conf files. The postgresql.conf.sample it's being fed is
> fairly pristine.
Indeed. Why in the world are you looking at initdb? The standard
reference for postgresql.conf-reading code, by definition, is
guc-file.l. I think the odds of building something that works right,
without borrowing that same flex logic, are about nil.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
