Re: Planning incompatibilities for Postgres 10.0
От | Daniel Farina |
---|---|
Тема | Re: Planning incompatibilities for Postgres 10.0 |
Дата | |
Msg-id | CACN56+Or_+KUMcU3Y6mbpeM-CY_groU37QP1WepaMeQYWOe4uw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Planning incompatibilities for Postgres 10.0 (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
On Mon, May 27, 2013 at 9:41 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 27 May 2013 15:36, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Bruce Momjian <bruce@momjian.us> writes: >>> On Mon, May 27, 2013 at 08:26:48AM -0400, Stephen Frost wrote: >>>> That said, many discussions and ideas do get shut down, perhaps too >>>> early, because of pg_upgrade considerations. If we had a plan to have >>>> an incompatible release in the future, those ideas and discussions might >>>> be able to progress to a point where we determine it's worth it to take >>>> the pain of a non-pg_upgrade-supported release. That's a bit of a >>>> stretch, in my view, but I suppose it's possible. Even so though, I >>>> would suggest that we put together a wiki page to list out those items >>>> and encourage people to add to such a list; perhaps having an item on >>>> that list would make discussion about it progress beyond "it breaks >>>> pg_upgrade". >> >>> Yes, we should be collecting things we want to do for a pg_upgrade break >>> so we can see the list all in one place. >> >> Precisely. We've said right along that we reserve the right to have a >> non-upgradable disk format change whenever sufficiently many reasons >> accumulate to do that. Here's one that's come up a few times: being able to tweak the out-of-line storage strategy, e.g. change the compression format used.I think some folks were lamenting the lack of a convenientbyte in the right place for that one.
В списке pgsql-hackers по дате отправления: