From: Nico Williams <nico@cryptonector.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: David Fetter <david@fetter.org>
Cc: Christian Convey <christian.convey@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Tackling JsonPath support
Date: Mon, 28 Nov 2016 13:23:43 -0600
Message-ID: <20161128192343.GD11117@localhost> (raw)
In-Reply-To: <CAFj8pRCSj4hQ_rOODyPp91asPdiLWLqTDcjJmxwjoaUfH1h_cQ@mail.gmail.com>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On Mon, Nov 28, 2016 at 05:56:41PM +0100, Pavel Stehule wrote:
> Dne 28. 11. 2016 17:26 napsal uživatel "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.
>
> 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
>
> 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 = jv_array();
a = 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 = jv_array_append(jv_array(), jv_true());
or
jv a = 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
--
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nico@cryptonector.com, pavel.stehule@gmail.com, david@fetter.org, christian.convey@gmail.com, tgl@sss.pgh.pa.us
Subject: Re: Tackling JsonPath support
In-Reply-To: <20161128192343.GD11117@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox