> Not sure which ones Simon meant, but at least any new/better > storage manager would seem to me to be requiring > a non-pg_upgrade upgrade path unless we require the storage manager > to also include a parallel implementation of pg_upgrade.
Isn't this a bit of horse-cart inversion here? We just hashed out a tentative, incomplete pseudo-spec for storage managers *yesterday*. We don't have a complete spec at this point, let alone a development plan, and it's entirely possible that we'll be able to implement SMs without breaking pgupgrade. It's also not at all clear that we can develop SMs in less than 2 years. I tend to think it unlikely. First, let's have a few features for which breaking binary compatibility is a necessity or a clear benefit. Then we'll schedule when to break them. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
