Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Fri, Jun 21, 2019 at 12:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Ah, got it. So it seems like the correct behavior might be for
> >> ALTER SYSTEM to
> >> (a) run through the whole file and remove any conflicting lines;
> >> (b) append new setting at the end.
>
> > That is exactly the behavior for which I am arguing. Stephen also
> > wants a warning, but I disagree, because the warning is totally
> > non-actionable. It tells you that some tool, at some point in the
> > past, did something bad. You can't do anything about that, and you
> > wouldn't need to except for the arbitrary decision to label duplicate
> > lines as bad in the first place.
>
> Agreed; there's no particular reason to consider the situation as wrong.
> guc.c has always had the policy that dups are fine and the last one wins.
> The very design of ALTER SYSTEM owes its workability to that policy, so
> we can hardly say that A.S. should have a different policy internally.
>
> The problem here is simply that ALTER SYSTEM is failing to consider the
> possibility that there are dups in postgresql.auto.conf, and that seems
> like little more than an oversight to be fixed.
>
> There's more than one way we could implement a fix, perhaps, but I don't
> really see a reason to work harder than is sketched above.
Why bother removing the duplicate lines?
If ALTER SYSTEM should remove them, why shouldn't other tools?
> (BTW, has anyone checked whether ALTER SYSTEM RESET is prepared to remove
> multiple lines for the same var?)
No, it doesn't handle that today either, as discussed earlier in this
thread.
If we want to get to should/must kind of language, then we could say
that tools should remove duplicated values, and must append to the end,
but I'm not sure that really changes things from what I'm proposing
anyway.
Thanks,
Stephen