On Sat, 2013-05-25 at 10:39 +0100, Simon Riggs wrote:
> The constraint on such changes is that we've decided that we must have
> an upgrade path from release to release.
Is this proposal only relaxing the binary upgrade requirement, or would
it also relax other compatibility requirements, such as language and API
compatibility?
We need a couple major drivers of the incompatibility that really show
users some value for going through the upgrade pain. Preferably, at
least one would be a serious performance boost, because the users that
encounter the most logical upgrade pain are also the ones that need a
performance boost the most.
Before we set a specific schedule, I think it would be a good idea to
start prototyping some performance improvements that involve breaking
the data format. Then, depending on how achievable it is, we can plan
for however many more 9.X releases we think we need. That being said, I
agree with you that planning in advance is important here, so that
everyone knows when they need to get format-breaking changes in by.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
