Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On Fri, Aug 02, 2019 at 06:08:02PM -0700, Andres Freund wrote:
>> We're WAY WAY past feature freeze. This isn't the time to rewrite guc.c,
>> guc-file.l to be suitable for running outside of a backend environment.
> Right. And even if we had the code, it's not quite backpatchable (which
> we probably should do, considering this is a general ALTER SYSTEM issue,
> so not pg12-only).
> Not to mention there's no clear consensus this is actually desirable.
> I'd argue forcing external tools (written in arbitrary language) to use
> this library (written in C), just to modify a "stupid" text file is a
> bit overkill. IMO duplicates don't make the file invalid, we should
> handle that correctly/gracefully, so I don't see why external tools
> could not simply append to the file. We can deduplicate the file when
> starting the server, on ALTER SYSTEM, or some other time.
Yup. I'd also point out that even if we had a command-line tool of this
sort, there would be scenarios where it's not practical or not convenient
to use. We need not go further than "my tool needs to work with existing
PG releases" to think of good examples.
I think we should just accept the facts on the ground, which are that
some tools modify pg.auto.conf by appending to it, and say that that's
supported as long as the file doesn't get unreasonably long.
I'm not at all on board with inventing a requirement for pg.auto.conf
to track its modification history. I don't buy that that's a
widespread need in the first place; if I did buy it, that file
itself is not where to keep the history; and in any case, it'd be
a new feature and it's way too late for v12.
regards, tom lane