Re: pg_migrator and handling dropped columns - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: pg_migrator and handling dropped columns
Date
Msg-id 499532CC.5020702@gmx.net
Whole thread Raw
In response to Re: pg_migrator and handling dropped columns  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_migrator and handling dropped columns
List pgsql-hackers
Tom Lane wrote:
>> Is this acceptable to everyone?  We could name the option
>> -u/--upgrade-compatible.
> 
> If the switch is specifically for pg_upgrade support (enabling this as
> well as any other hacks we find necessary), which seems like a good
> idea, then don't chew up a short option letter for it.  There should be
> a long form only.

Note that pg_dump's output is already upgrade compatible.  That's what 
pg_dump is often used for after all.  I believe what we are after here 
is something like "in-place upgrade compatible" or "upgrade binary 
compatible".

> And probably not even list it in the user documentation.

I think we should still list it somewhere and say it is for use by 
in-place upgrade utilities.  It will only confuse people if it is not 
documented at all.


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: WIP: hooking parser
Next
From: Peter Eisentraut
Date:
Subject: Re: pg_restore --multi-thread