agora inbox for [email protected]
help / color / mirror / Atom feedFrom: Nico Williams <[email protected]>
To: Christian Convey <[email protected]>
Cc: Pavel Stehule <[email protected]>
Cc: David Fetter <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Tom Lane <[email protected]>
Subject: Re: Tackling JsonPath support
Date: Mon, 28 Nov 2016 20:26:24 -0600
Message-ID: <20161129022623.GB24797@localhost> (raw)
In-Reply-To: <CAPfS4ZwgHT5FkRm8LE0ucG97e36ziBm0Pc-GkyGC15ksTwVFpw@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>
<20161128192343.GD11117@localhost>
<CAPfS4ZwgHT5FkRm8LE0ucG97e36ziBm0Pc-GkyGC15ksTwVFpw@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
On Mon, Nov 28, 2016 at 05:50:40PM -0800, Christian Convey wrote:
> On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams <[email protected]>
> wrote:
> ...
> > JSON Path is not expressive enough (last I looked) and can be mapped
> > onto jq if need be anyways.
>
> Hi Nico,
>
> Could you please clarify what you mean by "not expressive enough"?
jq is a functional language that has these and other features:
- recursion
- generators
- lazy evaluation (of sorts)
- path expressions
- math functionality (libm, basically)
- reduction
- functions
- and other things
(jq does not have higher-order functions in that functions cannot return
functions and functions are not values, though it does have closures.)
jq is and feels a lot like a SQL, but for JSON.
> I ask because I've been struggling to identify clear requirements for the
> json-path functionality I'm trying to provide. It sounds like perhaps you
> have something concrete in mind.
SQL imposes structure on data. Recursion makes SQL structure looser in
the sense that it may not be easy or possible to express certain
desirable schema constraints in SQL terms without resorting to triggers,
say. Storing documents in XML, JSON, or other such recursion-friendly
formats (perhaps in semantically equivalent but query-optimized forms)
is also a way to avoid strict structure (thus one needs schema
validators for XML, for example).
Less rigid schema constraints do not and should not preclude powerful
query languages.
One could convert such documents to a SQL EAV schema, if one has an
RDBMS with an ANY type (e.g., something like SQLite3's duck typing), and
then use SQL to query them. But that may be more difficult to use than
a SQL with support for XML/JSON/... and query sub-languages for those.
SQL is very powerful. One might like to have similarly powerful,
format-specific query languages for documents stored in XML, JSON,
etcetera, in a SQL RDBMS. jq is such a language, for JSON documents.
Ditto XPath/XSLT, for XML. While XPath is expressive and compact, XSLT
is rather verbose; jq is as expressive as XSLT, but with the compact
verbosity of XPath.
> Since I myself have no need currently for this functionality, I'm left
> guessing about hypothetical users of it. My current mental model is:
That's a bit like asking what is the use for SQL :^) The point is that
SQL is a powerful query language, and so is jq. Each is appropriate to
its own domain; both could be used together.
> (a) Backend web developers. AFAICT, their community has mostly settled on
> the syntax/semantics proposed by Stefan Groessner. It would probably be
> unkind for PG's implementation to deviate from that without a good reason.
I can't speak for the community. I wouldn't take it personally that jq
be not chosen, nor any other proposal of mine. If it's politically
easier, then do that.
> (b) PG hackers who will eventually implement the ISO SQL standard
> operators. In the standards-committee meeting notes I've seen, it seemed
> to me that they were planning to define some operators in terms of
> json-path expression. So it would probably be good if whatever json-path
> function I implement turns out to comply with that standard, so that the
> PG-hackers can use it as a building block for their work.
These could still be implemented (e.g., using jq itself).
> (c) Pavel. (I'm still somewhat unclear on what has him interested in this,
> and what his specific constraints are.)
Hmm?
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: <20161129022623.GB24797@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