Re: jsonb and nested hstore

Le jeudi 6 mars 2014 09:33:18 Andrew Dunstan a écrit :
> On 03/06/2014 08:16 AM, Oleg Bartunov wrote:
> > On Thu, Mar 6, 2014 at 12:43 PM, Peter Geoghegan <pg@heroku.com> wrote:
> >> On Thu, Mar 6, 2014 at 12:23 AM, Teodor Sigaev <teodor@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.

I haven't followed the whole thread, but json is really restrictive on the
supported types: a hierarchical hstore could maybe support more types
(timestamp comes to mind) as its values, which is not a valid data type in the
json spec.

>
> Whatever we do, rest assured your work won't go to waste.
>
> cheers
>
> andrew

--
Ronan Dunklau
http://dalibo.com - http://dalibo.org