Re: GSoC 2015: Extra Jsonb functionality

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Thom Brown <thom(at)linux(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GSoC 2015: Extra Jsonb functionality
Date: 2015-03-20 11:21:38
Message-ID: CA+q6zcUuDxB96Zbaa2dGMw1PmxR+PqAVTqUZb-tbn00PG-259Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Perhaph it's my misunderstanding, but this would seem to be more of an
intersection operation on keys rather than a delete.
Hm...why? We remove all elements, which are contains in the first and
second jsonb ("f": [4, 5] in this case) from the first one.

> Could there be a corresponding jsonb_except function which does the
opposite (i.e. returns everything on the left side except where it matches
with the right)?
and if I understand your question correctly, this is exactly what the
jsonb_delete_jsonb will do, isn't it?.

> Is there a use-case for the example you've given above, where you take
JSON containing objects and arrays, and flatten them out into a
one-dimensional array?
Hm...actually I don't know about such use-cases. This function is analog of
the hstore_to_array (and the similar function hstore_to_matrix), which is
used sometimes, judging by github. So I thought this function should be
implemented (after this question I'm not so sure).

> What should happen if "g" or {"g"} were used instead?
Did you mean {"g": "key"}? Hmm...but in any case, I suppose this new object
should be appended to the array as a regular element.
=# jsonb_add_to_path('{"b": {"c": ["d", "f"]}}'::jsonb, {b, c}::text[],
'"g"'::jsonb);

jsonb_add_to_path
---------------------------------------
{"b": {"c": ["d", "f", "g"]}}

> This is a bit strange. Why did "f" get flattened out of "d"?
The main purpose if this function is to get values for required keys from
all nesting levels (actually, I thougth it will be not so convenient
otherwise and I didn't consider the implementation with path usage). If
this so confusing, I can remove this function from the list =)

On 20 March 2015 at 00:08, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:

> Thom Brown wrote:
> > On 19 March 2015 at 14:35, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
> wrote:
> > > Thom Brown wrote:
> > >> On 19 March 2015 at 14:12, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
> wrote:
> > >> > Dmitry Dolgov wrote:
> > >> >
> > >> >> * jsonb_slice - extract a subset of an jsonb
> > >> >> Example of usage:
>
> > Okay, so it pulls it all parents? So I guess you'd get this too:
> >
> > SELECT jsonb_slice('{"a": 1, "b": {"c": 2}, "d": {"f": 3}, "f":
> > 4}'::jsonb, ARRAY['b', 'f', 'x']);
> >
> > jsonb_slice
> > ------------------------------------------------
> > {"a": 1, "b": {"c": 2}, "d": {"f": 3}, "f": 4}
>
> Yeah, except "a" wouldn't be output, of course. (The example gets more
> interesting if "d" contains more members than just "f". Those would not
> get output.)
>
>
> > >> Although I'm still a bit confused about "f" being produced.
> > >
> > > I guess you could say that the second argument is an array of element
> > > paths, not key names. So to get the result I suggest, you would have
> to
> > > use ARRAY['{b}', '{d,f}', '{x}']. (Hm, this is a non-rectangular
> > > array actually... I guess I'd go for ARRAY['b', 'd//f', 'x'] instead,
> or
> > > whatever the convention is to specify a json path).
> >
> > I think that's where jsquery would come in handy.
>
> If that's what we think, then perhaps we shouldn't accept jsonb_slice at
> all because of ambiguous mode of operation.
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message hitesh ramani 2015-03-20 11:26:13 Re: GSoC - Idea Discussion
Previous Message Max Filippov 2015-03-20 11:01:56 Re: configure can't detect proper pthread flags