Re: jsonpath
От | Alexander Korotkov |
---|---|
Тема | Re: jsonpath |
Дата | |
Msg-id | CAPpHfdsxacOREFDAhhZFwL=-x8Z49LCrEK8T9Zn=SJY-EJ+S_Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: jsonpath (Nikita Glukhov <n.gluhov@postgrespro.ru>) |
Ответы |
Re: jsonpath
Re: jsonpath |
Список | pgsql-hackers |
On Tue, Jan 29, 2019 at 2:17 AM Nikita Glukhov <n.gluhov@postgrespro.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: http://www.postgrespro.com The Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: