Skip site navigation (1) Skip section navigation (2)

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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [COMMITTERS] pgsql: Don't override arguments set via options with positional argumen
Date: 2012-04-18 14:27:08
Message-ID: 4F8ECF3C.8040902@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers

On 04/18/2012 10:03 AM, Peter Eisentraut wrote:
> On ons, 2012-04-18 at 09:53 -0400, Tom Lane wrote:
>> Peter Eisentraut<peter_e(at)gmx(dot)net>  writes:
>>> My vote is to revert this altogether and leave it be.  In the
>>> alternative, make it an error.
>> You mean in HEAD too?  I don't agree with that, for sure.  What this
>> patch is accomplishing is to make sure that the less-commonly-used
>> programs have similar command-line-parsing behavior to psql and pg_dump,
>> where we long ago realized that failure to check this carefully could
>> result in very confusing behavior.  (Especially on machines where
>> getopt is willing to rearrange the command line.)
> OK, if you care strongly about that, make it an error.  But don't just
> ignore things.


It won't be ignored. It will be caught by the "too many arguments" logic.

The case where repeated arguments should be disallowed is a similar but 
different case that probably demands a much larger patch. I don't think 
its existence militates against this fix, however.


>
>> I agree with Andrew that this is a bug fix.  I can see the argument
>> for not applying it to back branches, but not for declaring that it's
>> not a bug.
> We shouldn't be backpatching things that are merely confusing.  It works
> as designed at the time, after all.  Improvements belong in master.
>


If it was really intended to work this way then that's a piece of very 
poor design, IMNSHO. It looks to me much more like it was just an 
oversight.

I don't have terribly strong feelings about this, since we've not had 
lots of complaints over the years, so I'll revert it in the back branches.

cheers

andrew

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-04-18 14:29:26
Subject: Re: Bug tracker tool we need
Previous:From: Peter EisentrautDate: 2012-04-18 14:19:37
Subject: Re: Bug tracker tool we need

pgsql-committers by date

Next:From: Robert HaasDate: 2012-04-18 14:47:13
Subject: pgsql: Fix copyfuncs/equalfuncs support for ReassignOwnedStmt.
Previous:From: Robert HaasDate: 2012-04-18 14:12:01
Subject: pgsql: Doc clarification for synchronous_commit.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group