From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Planning incompatibilities for Postgres 10.0 |
Date: | 2013-05-26 15:18:10 |
Message-ID: | 51A227B2.8070602@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2013-05-26 15:32:26 | Re: Processing long AND/OR lists |
Previous Message | Tom Lane | 2013-05-26 15:02:19 | Re: View Index and UNION |