Date: Mon, 28 Nov 2016 13:23:43 -0600
From: Nico Williams <nico@cryptonector.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: David Fetter <david@fetter.org>,
	Christian Convey <christian.convey@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
	Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Tackling JsonPath support
Message-ID: <20161128192343.GD11117@localhost>
References: 
 <CAPfS4Zy0RCJstWT3sRhKZO6db+xxZeAL7wmOVG5QUK=P8bXWZQ@mail.gmail.com>
 <CAFj8pRA2BbWioAfA79bDdJ_JviVaUYr+5zj+sQuVrHmvJARKdw@mail.gmail.com>
 <CAPfS4ZwaPMMLUQ6AFj=t182AAce-wGcDWzP9nHqkz3nx+H2_2Q@mail.gmail.com>
 <20681.1479057226@sss.pgh.pa.us>
 <CAFj8pRDvKiQ3YcNOCeEcOEy+OKh6LFcazmOe-Tit-gHyv1e+xQ@mail.gmail.com>
 <CAPfS4Zx8v1xx_OoG6n2_K2TthNudGshfkSbk=-__N+1-z8WSwg@mail.gmail.com>
 <20161128162639.GB27143@fetter.org>
 <CAFj8pRCSj4hQ_rOODyPp91asPdiLWLqTDcjJmxwjoaUfH1h_cQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
 <CAFj8pRCSj4hQ_rOODyPp91asPdiLWLqTDcjJmxwjoaUfH1h_cQ@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Mon, Nov 28, 2016 at 05:56:41PM +0100, Pavel Stehule wrote:
> Dne 28. 11. 2016 17:26 napsal u=C5=BEivatel "David Fetter" <david@fetter.=
org>:
> > There's another option we should also consider: jq
> > <https://stedolan.github.io/jq/>.  It's available under a
> > PostgreSQL-compatible license, and has had a LOT of work put into
> > correctness and performance.
>=20
> we can use it for inspiration. but the syntax of this tool is little bit
> too complex and too original against Json path ... jsonpath is relative
> simple implementation of xpath to json
>=20
> we have one proprietary syntax already, two is maybe too much :-)

jq is hardly proprietary :)

JSON Path is not expressive enough (last I looked) and can be mapped
onto jq if need be anyways.

libjq has a number of desirable features, mostly its immutable/COW data
structures.  In libjq data structures are only mutated when there's
only one reference to them, but libjq's jv API is built around
immutability, so jv values are always notionally immutable.  For
example, one writes:

  jv a =3D jv_array();

  a =3D jv_array_append(a, jv_true()); // `a' is notionally new, but since
                                     // it had only one reference, its
                                     // memory is reused

and similarly for objects.  One could instead write:

  jv a =3D jv_array_append(jv_array(), jv_true());
=20=20
or

  jv a =3D JV_ARRAY(jv_true());

One of the nice things about libjv is that almost every function
consumes a reference of every jv value passed in, with very few
exceptions.  This simplifies memory management, or at least avoidance of
double-free and use-after-free (it can be harder to track down leaks
though, since tools like valgrind don't understand that jv_copy() call
sites can be like allocations).

Nico
--=20


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers