Re: Bug in jsonb_path_exists (maybe _match) one-element scalar/variable jsonpath handling

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Bug in jsonb_path_exists (maybe _match) one-element scalar/variable jsonpath handling
Дата
Msg-id CAKFQuwbRpF2bpSORTUqZW1rAonMyPjT_3RoGmqzPpr8rE9hyYQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Bug in jsonb_path_exists (maybe _match) one-element scalar/variable jsonpath handling  (Alexander Korotkov <aekorotkov@gmail.com>)
Ответы Re: Bug in jsonb_path_exists (maybe _match) one-element scalar/variable jsonpath handling
Список pgsql-bugs
Дерево обсуждения
On Fri, Dec 2, 2022 at 10:47 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:

> Thank you for explaining your point, but I can't agree with that.
> Constant jsonpath expression is always returning item for the input
> JSON value.  Even despite the input value is ignored.  This is
> redundant case, but still correct.

Let me explain more what I do mean.  In the SQL SELECT statement there
is a WHERE clause.  This clause should express the predicate, which
should match to rows.  But you're writing "WHERE 1 = 1" or "WHERE
true" then all rows are matching even that no column is referenced.
This is how SQL is working.  And I see no reason why jsonpath should
work in a different way.


I like the analogy but it seems to support my conclusion moreso than yours:

Consider: select jsonb_path_exists('{"foo":"bar"}'::jsonb, 'false');

The analogous SQL query is: "SELECT * FROM table WHERE false" would indeed produce an empty set - which EXISTS would interpret as false but you want to evaluate to true

Or, "SELECT * FROM table WHERE 'banana';" which produces the same kind of error that I wish jsonb_path_exists would produce when one writes a similarly nonsensical path.

David J.

I'll probably get to a formal review of the patch - but actually I am hoping someone else more comfortable in the codebase chimes in here with an opinion.  Though as I said, I'm willing to concede that the behavior should probably stay unchanged, for compatibility reasons, and we just need to decide on how to correctly document this.

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Kyle Spearrin
Дата:
Сообщение: CREATE COLLATION without LOCALE throws error in v15
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: hashing bpchar for nondeterministic collations is broken