> 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