On Wed, Mar 5, 2014 at 2:45 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Merlin Moncure escribió:
>> 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.
Certainly. The important point though is that neither option is
available if the old stuff is locked into the public namespace.
Consider various warts like the array ('array_upper' et al) API or geo
types. We're stuck with them. Even with jsonb: it may be the hot new
thing *today* but 5 years down the line there's json2 that does all
kinds of wonderful things we haven't thought about -- what if it
displaces current usages? The very same people who are arguing that
jsonb should not be in an extension are the ones arguing json is
legacy and to be superseded. These two points of view IMO are
directly in conflict: if json would have been an extension than the
path to deprecation is clear. Now the json functions are in the
public namespace. Forever (or at least for a very long time).
On Wed, Mar 5, 2014 at 2:46 PM, Stephen Frost <sfrost@snowman.net> wrote:
> I don't see why we can't do exactly what you're suggesting in core.
Because you can't (if you're defining core to mean 'not an
extension'). Functions can't be removed or changed because of legacy
application support. In an extension world, they can -- albeit not
'magically', but at least it can be done.
merlin