On Thu, Sep 23, 2010 at 1:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Sep 23, 2010 at 1:29 PM, Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
