Re: pg_upgrade project status

Tom Lane wrote:
> The appeal of the pg_dump approach is that it will automatically handle
> everything that there exists a plain-SQL representation for, which is to
> say darn near everything.  We will need special purpose code to deal
> with the dropped-column and TOAST-oid issues, but that can probably be
> written in SQL if it makes anyone feel better to do so ;-).  The more
> important point is that once we're done with those two issues, we're
> done, and will stay done for the foreseeable future (at least with
> respect to catalog upgrades).
> 
> I am not sure why everyone is so hot to create a conversion path that
> guarantees extra maintenance pain for every future catalog
> reorganization, when it would be no more complex to create one without
> such a burden.

I am stumped as well.  In the 12 years I have been involved, there are
perhaps five issues that the original pg_upgrade written in 1998 didn't
handle, and mostly handles now.  Considering the number of catalog
changes since 1998, the ratio is enormous.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +