On 03/06/2014 05:46 PM, Tom Lane wrote:
Magnus Hagander <mag...@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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to