Re: jsonb and nested hstore

On 03/06/2014 05:46 PM, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> However, if the new hstore type (compatible with the old one) is the
>> wrapper around jsonb, rather than the other way around, I don't see any
>> problem with it at all. Most future users are almost certainly going to use
>> the json interfaces, but we don't want to leave upgraded users behind. (But
>> of course it has to actually maintain backwards compatibility for that
>> argument to hold)
>
> Yeah --- all of this turns on whether hstore improvements can be 100%
> upwards compatible or not.  If they are, I don't object to including them;

There are reasons for *not* wanting the new hstore2 functionality. If 
you don't want nesting, for example, with the new type you're going to 
need to add a constraint to forbid that. Ugh. Many applications are 
happy with the current functionality, a simple string key/value 
dictionary, and for them the new features are not an improvement.

As an analogy, adding significant new functionality like nesting to the 
existing hstore type is like suddenly adding the time of day to the date 
datatype. It might be useful in many cases. And an existing application 
can leave the hour and minute fields zero, so it's backwards-compatible. 
But as soon as someone inserts a datum that uses the hour and minute 
fields, it will confuse the application that doesn't know about that.

I haven't been following these discussions closely, but for those 
reasons, I thought hstore2 was going to be a separate type. I don't 
think there are very many applications that would be interested in 
"upgrading" from the current hstore to the new hstore2 type. More 
likely, the new data type is useful for many applications that couldn't 
have used hstore before because it didn't support nesting or was too 
loosely typed. And old applications that are already using hstore are 
perfectly happy with the status quo.

Let's not mess with the existing hstore datatype. For what it does, it 
works great.

Likewise, jsonb is significantly different from hstore2, so it should be 
a separate data type. Frankly I don't understand what the problem is 
with doing that. I don't have a problem with copy-pasting the common parts.

BTW, now that I look at the nested hstore patch, I'm disappointed to see 
that it only supports a few hardcoded datatypes. Call me naive, but 
somehow I thought it would support *all* PostgreSQL datatypes, built-in 
or user-defined. I realize that's a tall order, but that's what I 
thought it did. Since it doesn't, color me unimpressed. It's really not 
any better than json, I don't see why anyone would prefer it over json. 
Not that I particularly like json, but it's a format a lot of people are 
familiar with.

So here my opinion on what we should do:

1. Forget about hstore2
2. Add GIN and GIST operator classes to jsonb, if they're ready for 
commit pretty darn soon. If not, punt them to next release.

- Heikki