Re: pg_upgrade docs - Mailing list pgsql-hackers

From Stefan Kaltenbrunner
Subject Re: pg_upgrade docs
Date
Msg-id 4BFACC97.9090809@kaltenbrunner.cc
Whole thread Raw
In response to Re: pg_upgrade docs  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_upgrade docs
List pgsql-hackers
On 05/24/2010 07:43 PM, Bruce Momjian wrote:
> Stefan Kaltenbrunner wrote:
>> On 05/19/2010 05:16 PM, Bruce Momjian wrote:
>>> Andres Freund wrote:
>>>> On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote:
>>>>> There are some limitations when migrating from 8.3 to 8.4, but not when
>>>>> migrating from 8.3 to 9.0, because we added a feature to 9.0.  Can you
>>>>> give a specific example?
>>>> Didnt the 'name' alignment change?
>>>
>>> Uh, the heading above that item is:
>>>
>>>    <title>Limitations in migrating<emphasis>from</>  PostgreSQL
>>>    8.3</title>
>>>
>>> What is unclear there?  It covers going to 8.4 and 9.0.
>>
>> well the wording makes it kinda unclear on what happens if you go FROM
>> 8.4 to 9.0. If there are no known limits we might want to add a small
>> note saying so. If there are some we might want to restructure the
>> paragraph a bit...
>
> Sorry for the delay in replying.  The section you list is titled:
>
>     F.31.4. Limitations in migrating from PostgreSQL 8.3
>
>     http://developer.postgresql.org/pgdocs/postgres/pgupgrade.html
>
> and the first sentence is:
>
>     pg_upgrade will not work for a migration from 8.3 if a user column
>
> I have updated the paragraph to be:
>
>     Upgrading from PostgreSQL 8.3 has additional restrictions not present
>     when upgrading from later PostgreSQL releases.  For example,
>     pg_upgrade will not work for a migration from 8.3 if a user column
>     is defined as:
>
> Can you suggest other wording?

hmm that seems better thanks, however I just noticed that we don't have 
a "general limitations" section. The way the docs are now done suggests 
that there are not limitations at all (except for the two warnings in 
the migration guide). Is pg_upgrade really up to the point where it can 
fully replace pg_dump & pg_restore independent of the loaded (contrib) 
or even third party modules(like postgis or custom datatypes etc)?



Stefan


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: beta testing - pg_upgrade bug fix - double free
Next
From: Robert Haas
Date:
Subject: Re: Exposing the Xact commit order to the user