Merlin Moncure escribió: > On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost <sfr...@snowman.net> wrote:
> > We have backwards compatibility "problems" because we don't want to > > *break* things for people. Moving things into extensions doesn't > > magically fix that- if you break something in a backwards-incompatible > > way then you're going to cause a lot of grief for people. > > It doesn't magically fix it, but at least provides a way forward. If > the function you want to modify is in an extension 'foo', you get to > put your new stuff in 'foo2' extension. That way your users do not > have to adjust all the code you would have broken. Perhaps for > in-core extensions you offer the old one in contrib for a while until > a reasonable amount of time passes then move it out to pgxn. Uhm. Would it work to define a new version of foo, say 2.0, but keep the old 1.2 version the default? That way, if you want to keep the old foo you do nothing (after both fresh install and pg_upgrade), and if you want to upgrade to the new code, it's just an ALTER EXTENSION UPDATE away. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
