Re: jsonb and nested hstore

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Hannu Krosing <hannu(at)2ndquadrant(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: jsonb and nested hstore
Date: 2014-02-26 15:02:46
Message-ID: CAHyXU0xsrN_Zaf=4taqr2DQDsOGSp54Ab0Dd0NJvX6fqjQCZbg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
> On 02/25/2014 08:54 PM, Josh Berkus wrote:
>> That's called a "straw man argument", Robert.
>> Me: We should recommend that people use jsonb unless they have a
>> specific reason for using json.
> We could also make the opposite argument - people use json unless they
> have a specific reason for using jsonb.
>
> btw, there is one more thing about JSON which I recently learned - a lot of
> JavaScript people actually expect the JSON binary form to retain field order
>
> It is not in any specs, but nevertheless all major imlementations do it and
> some code depends on it.
> IIRC, this behaviour is currently also met only by json and not by jsonb.

Yes: This was the agreement that was struck and is the main reason why
there are two json types, not one. JSON does not guarantee field
ordering as I read the spec and for the binary form ordering is not
maintained as a concession to using the hstore implementation.

You can always use the standard text json type for storage and cast
into the index for searching; what you give up there is some
performance and the ability to manipulate the json over the hstore
API. I think that will have to do for now and field ordering for
hstore/jsonb can be reserved as a research item.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2014-02-26 15:15:00 Re: ALTER TABLE lock strength reduction patch is unsafe
Previous Message Sandro Santilli 2014-02-26 15:01:13 Re: Uninterruptable regexp_replace in 9.3.1 ?