Re: Re: [COMMITTERS] pgsql: Don't override arguments set via options with positional argumen - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Don't override arguments set via options with positional argumen
Date
Msg-id 17423.1334717624@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Don't override arguments set via options with positional argumen  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Re: [COMMITTERS] pgsql: Don't override arguments set via options with positional argumen  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> You know, I could have sworn it was discussed, but when I look back I 
> see it wasn't. I must have been remembering the recent logging protocol bug.

> I'll revert it if people want, although I still think it's a bug.

I think we discussed it to the extent of agreeing it was a bug, but
the question of whether to back-patch was not brought up.

I can see both sides of this.  I agree that the old behavior is buggy,
but what I imagine Robert is worried about is scripts that accidentally
work okay today and would stop working once the PG programs are fixed
to complain about bogus usage.  People tend not to like it if you make
that kind of change in a minor release.  Against that you have to set
the probability of mistaken interactive usage being caught, or not,
by a repaired program.  Stopping a disastrous command-line typo seems
potentially worth any pain from having to fix scripts that would have
to be fixed eventually anyway.

If you had patched only HEAD I would have been fine with that, but
seeing that you've done the work to back-patch I'm kind of inclined
to let it stand.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bug tracker tool we need
Next
From: "Greg Sabino Mullane"
Date:
Subject: Re: Bug tracker tool we need