Re: jsonpath

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Oleg Bartunov <obartunov(at)postgrespro(dot)ru>, Michael Paquier <michael(at)paquier(dot)xyz>, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, David Steele <david(at)pgmasters(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: jsonpath
Date: 2019-01-29 01:00:19
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Tue, Jan 29, 2019 at 2:17 AM Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru> wrote:
> In the previous version of the patch jsonb_path_match() threw error when
> jsonpath did not return a singleton value, but in the last version in such cases
> NULL is returned. This problem arises because we cannot guarantee at compile
> time that jsonpath expression used in jsonb_path_match() is a predicate.
> Predicates by standard can return only True, False, and Unknown (errors occurred
> during execution of their operands are transformed into Unknown values), so
> predicates cannot throw errors, and there are no problems with errors.

Attached patchset provides description of errors suppressed. It also
clarifies how jsonb_path_match() works.

> GIN does not attempt to search non-predicate expressions, so there may be no
> problem even we throw "not a singleton" error.

Yes, I don't insist on that. If majority of us wants to bring "not a
singleton" error back, I don't object to it.

> Here I want to remind that ability to use predicates in the root of jsonpath
> expression is an our extension to standard that was created specially for the
> operator @@. By standard predicates are allowed only in filters. Without this
> extension we are still able to rewrite @@ using @?:
> jsonb @@ 'predicate' is equivalent to
> jsonb @? '$ ? (predicate)'
> but such @? expression is a bit slower to execute and a bit verbose to write.
> If we introduced special type 'jsonpath_predicate', then we could solve the
> problem by checking the type of jsonpath expression at compile-time.

For me it seems that separate datatype for this kind of problem is overkill.

> Another problem with error handling is that jsonb_path_query*() functions
> always throw SQL/JSON errors and there is no easy and effective way to emulate
> NULL ON ERROR behavior, which is used by default in SQL/JSON functions. So I
> think it's worth trying to add some kind of flag 'throwErrors' to
> jsonb_path_query*() functions.

Good idea, but let's commit basic jsonpath implementation first.

Alexander Korotkov
Postgres Professional:
The Russian Postgres Company

Attachment Content-Type Size
0001-Preliminary-datetime-infrastructure-v32.patch application/octet-stream 32.6 KB
0002-Jsonpath-engine-and-docs-v32.patch application/octet-stream 293.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-01-29 01:03:32 Re: jsonpath
Previous Message Andres Freund 2019-01-29 00:55:53 Re: Header checking failures on LLVM-less machines