Re: Passing connection string to pg_basebackup - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Passing connection string to pg_basebackup
Date
Msg-id CA+TgmoZXuegu72FG6mRAvrq6bUavCoYreJ-j1okn6um_-upp7w@mail.gmail.com
Whole thread Raw
In response to Re: Passing connection string to pg_basebackup  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jan 19, 2013 at 12:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
>> On the other hand, discrepancies in between command line arguments
>> processing in our tools are already not helping our users (even if
>> pg_dump -d seems to have been fixed along the years); so much so that
>> I'm having a hard time finding any upside into having a different set of
>> command line argument capabilities for the same tool depending on the
>> major version.
>
>> We are not talking about a new feature per se, but exposing a feature
>> that about every other command line tool we ship have. So I think I'm
>> standing on my position that it should get backpatched as a "fix".
>
> I don't think that argument holds any water at all.  There would still
> be differences in command line argument capabilities out there ---
> they'd just be between minor versions not major ones.  That's not any
> easier for people to deal with.  And what will you say to someone whose
> application got broken by a minor-version update?

I heartily agree.  I can say from firsthand experience that when minor
releases break things for customers (and they do), the customers get
*really* cranky.  Based on recent experience, I think we should be
tightening our standards for what gets back-patched, not loosening
them.  (No, I don't have a specific example off-hand, sorry.)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [WIP] pg_ping utility
Next
From: Dean Rasheed
Date:
Subject: Re: Reporting hba lines