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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
