agora inbox for [email protected]  

help / color / mirror / Atom feed

From: Nico Williams <[email protected]>
To: Pavel Stehule <[email protected]>
Cc: David Fetter <[email protected]>
Cc: Christian Convey <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Tom Lane <[email protected]>
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>
	<[email protected]>
	<CAFj8pRDvKiQ3YcNOCeEcOEy+OKh6LFcazmOe-Tit-gHyv1e+xQ@mail.gmail.com>
	<CAPfS4Zx8v1xx_OoG6n2_K2TthNudGshfkSbk=-__N+1-z8WSwg@mail.gmail.com>
	<[email protected]>
	<CAFj8pRCSj4hQ_rOODyPp91asPdiLWLqTDcjJmxwjoaUfH1h_cQ@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?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" <[email protected]>:
> > 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

view thread (41+ messages)  latest in thread

reply

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  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 agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox