On Thu, Sep 23, 2010 at 1:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Sep 23, 2010 at 1:29 PM, Bruce Momjian <bruce@momjian.us> wrote:
>>> Josh Berkus wrote:
>>>> It would be a good project to add to the list of "easy TODOs to get
>>>> started with."
>
>>> Except for the pg_upgrade issue.
>
>> Which is a big "except".
>
> Yeah. That constraint is what leads me to think that the return on
> effort is just not worth it. Maybe we should file this in the category
> of "things to look at next time we break on-disk compatibility".
I'm worried about how we're going to manage that. First, as
pg_upgrade becomes more mature, the penalty for breaking on-disk
compatibility gets a LOT bigger. I'd like to think that "the next
time we break on-disk compatibility" means approximately "never", or
at least "not for a very long time". Second, if we do decide to break
it, how and when will we make that decision? Are we just going to
decide to break it when we run into a feature that we really want that
can't be had any other way? If we want to make breaking on-disk
compatibility something that only happens every 5 years or so, we had
better give people - I don't know, a year's notice - so that we can
really knock out everything people have any interest in fixing in one
release.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
