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
