| 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: | Whole Thread | Raw Message | 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 |