Re: jsonb and nested hstore

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Christophe Pettus <xof(at)thebuild(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: jsonb and nested hstore
Date: 2014-03-05 22:14:41
Message-ID: CAHyXU0xof6czcm78H-8HZ5X_6fycC8B3P3vJSVBX=h0zTV09Gg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 5, 2014 at 2:45 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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(at)snowman(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2014-03-05 22:15:31 Re: Disable hot-update functionality
Previous Message Robert Haas 2014-03-05 22:05:24 Re: Changeset Extraction v7.9.1