On 03/06/2014 08:16 AM, Oleg Bartunov wrote:
On Thu, Mar 6, 2014 at 12:43 PM, Peter Geoghegan <p...@heroku.com> wrote:
On Thu, Mar 6, 2014 at 12:23 AM, Teodor Sigaev <teo...@sigaev.ru> wrote:
That's possible to introduce GUC variable for i/o functions which will
control old "bug-to-bug" behavior. IMHO, this is much better option that
stopping hstore development or split hstore to two branches.
A GUC that controls i/o functions is generally considered to be an
unacceptable hack.
In what sense are we really stopping hstore development if hstore2
lives as jsonb? I have a hard time imagining someone dealing with the
incompatibility that a user-facing hstore2 would introduce, while
still preferring hstore syntax over json syntax given the choice.
There are very rich facilities for manipulating json available in
every programming language. The same is not true of hstore.
Having looked at the issue today, I think that the amount of redundant
code between a hstore2 in core as jsonb and hstore1 will be
acceptable. The advantages of making a clean-break in having to
support the legacy hstore disk format strengthen the case for doing so
too.
Heh, let's not to do an implusive decision about hstore2. I agree,
that jsonb has
a lot of facilities, but don't forget, that json(b) has to follow standard and
in that sense it's more constrained than hstore, which we could further
develop to support some interesting features, which will never be implemented
in json(b). Also, it'd be a bit awkward after working on nested
hstore and declaring it
on several conferences (Engine Yard has sponsored part of our hstore
work), suddenly
break people expectation and say, that our work has moved to core to
provide json
some very cool features, good bye, hstore users :( I'm afraid people
will not understand us.
Oleg,
I hear you, and largely agree, as long as the compatibility issue is
solved. If it's not, I think inventing a new hstore2 type is probably a
lousy way to go.
For good or ill, the world has pretty much settled on wanting to use
json for lightweight treeish data. That's where we'll get the most
impact. Virtually every programming language (including Perl) has good
support for json.
I'm not sure what the constraints of json that you might want to break
are. Perhaps you'd like to specify.
Whatever we do, rest assured your work won't go to waste.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
