|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>|
|Views:||Raw Message | Whole Thread | Download mbox|
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.
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
|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|