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 <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.
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
signature.asc
Description: This is a digitally signed message part.
