Re: pg_dumpall reccomendation in release notes - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: pg_dumpall reccomendation in release notes
Date
Msg-id 530D3DC5.3070802@agliodbs.com
Whole thread Raw
In response to pg_dumpall reccomendation in release notes  (Josh Berkus <josh@agliodbs.com>)
Responses Re: pg_dumpall reccomendation in release notes
List pgsql-hackers
On 02/25/2014 04:42 PM, Bruce Momjian wrote:
> On Tue, Feb 25, 2014 at 06:41:26PM -0500, Tom Lane wrote:
>> I'm not sure what "many limitations" you think pg_dumpall has that pg_dump
>> doesn't.
>>
>> I do think that it might be time to reword this to recommend pg_upgrade
>> first, though.  ISTM that the current wording dates from when pg_upgrade
>> could charitably be described as experimental.
> 
> Wow, so pg_upgrade takes the lead!  And from Tom too!  :-)
> 
> I agree with Tom that mentioning pg_dump/restore is going to lead to
> global object data loss, and throwing the users to a URL with no
> explaination isn't going to help either.  What we could do is to
> restructure the existing text and add a link to the upgrade URL for more
> details.

What I was suggesting was something like:

"Users upgrading from earlier versions will need to go through the
entire upgrade procedure, as described on our upgrade page: <link>"

The problem is that anything we say about "how to upgrade" in one short
sentence is going to confuse some people.  BTW, the reason I got that
question about pg_dump was that 9.2's release notes say "pg_dump" and
9.3's say "pg_dumpall", causing users to think there's been some kind of
change.

Of course, this means I need to fix the upgrade page, and I need to
write backported versions of that fix for at least 9.1 and 9.2.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: extension_control_path
Next
From: Alvaro Herrera
Date:
Subject: Re: In which good intentions are punished, take 2