Re: jsonb and nested hstore

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Oleg Bartunov <obartunov(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: jsonb and nested hstore
Date: 2014-02-05 15:48:20
Message-ID: CAHyXU0wpq+aN9EQZdVc3qC2cp_qeZBmzqwYtCxWyDFC-mQdY6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 5, 2014 at 12:44 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> send/recv functions are also needed for binary-format COPY. IMHO jsonb must
> have send/recv functions. All other built-in types have them, except for
> types like 'smgr', 'aclitem' and 'any*' that no-one should be using as
> column types.

Yes -- completely agree. I also consider the hstore functionality (in
particular, searching and access operators) to be essential
functionality.

I'm actually surprised we have an alternate binary wire format for
jsonb at all; json is explicitly text and I'm not sure what the use
case of sending the internal structure is. Meaning, maybe jsonb
send/recv should be a thin wrapper to sending the json string. The
hstore send/recv I think properly covers the case where client side
binary wire format actors would want to manage performance critical
cases that want to avoid parsing.

On Wed, Feb 5, 2014 at 1:21 AM, Oleg Bartunov <obartunov(at)gmail(dot)com> wrote:
> Andrew provided us more information and we'll work on recv. What
> people think about testing this stuff ? btw, we don't have any
> regression test on this.

I'm intensely interested in this work; I consider it to be transformative.

I've *lightly* tested the jsonb/hstore functionality and so far
everything is working.

I still have concerns about the API. Aside from the stuff I mentioned
upthread I find the API split between jsonb and hstore to be a little
odd; a lot of useful bits (for example, the @> operator) come via the
hstore type only. So these types are joined at the hip for real work
which makes the diverging incomplete behaviors in functions like
populate_record() disconcerting. Another point I'm struggling with is
what jsonb brings to the table that isn't covered either hstore or
json; working through a couple of cases I find myself not using the
jsonb functionality except as a 'hstore json formatter' which the json
type covers. I'm probably being obtuse, but we have to be cautious
before plonking a couple of dozen extra functions in the public
schema.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-02-05 16:22:55 Re: jsonb and nested hstore
Previous Message Amit Kapila 2014-02-05 15:36:05 Re: Performance Improvement by reducing WAL for Update Operation