Re: Planning incompatibilities for Postgres 10.0
От | Josh Berkus |
---|---|
Тема | Re: Planning incompatibilities for Postgres 10.0 |
Дата | |
Msg-id | 51A227B2.8070602@agliodbs.com обсуждение исходный текст |
Ответ на | Planning incompatibilities for Postgres 10.0 (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Planning incompatibilities for Postgres 10.0
Re: Planning incompatibilities for Postgres 10.0 |
Список | 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
В списке pgsql-hackers по дате отправления: