From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Christophe Pettus <xof(at)thebuild(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: jsonb and nested hstore |
Date: | 2014-02-28 21:35:31 |
Message-ID: | CAM3SWZRskhLCqLvQxUWLd5b_vyfOsFY+u8ssnA9g+nBCjB0eYg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 28, 2014 at 1:25 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> The only "dependency" is if you want to be able to use some advanced
> indexing and other functionality, for which we don't currently have jsonb
> equivalents of the new hstore operators, because we ran out of time. Then
> you can get this functionality by casting the data to hstore (assuming we
> also have nested-hstore committed) and using its operators. But that's no
> more a dependency than it is for any other type for which you can leverage
> this functionality (e.g. any record type).
I don't think hstore-style indexing is "advanced"; it's the main
reason for there being a jsonb, in my view. Anyway, this is where I
have a hard time understanding what you intend for jsonb for 9.4. You
ran out of time for writing jsonb operator classes, and so you can use
the hstore ones, which work fine. But, if we didn't run out of time,
how would the jsonb operator classes differ from the hstore ones? Is
there something inferior about the hstore operator class as compared
to a hypothetical jsonb operator class, other than the superficial
need to cast?
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe Pettus | 2014-02-28 21:38:06 | Re: jsonb and nested hstore |
Previous Message | Peter Geoghegan | 2014-02-28 21:34:29 | Re: jsonb and nested hstore |