Re: BUG #18510: jsonpath does not support trailing backslash at the end of the query

The following bug has been logged on the website:

Bug reference: 18510
Logged by: Lex Vorona
Email address: voronaam(at)gmail(dot)com
PostgreSQL version: 16.3
Operating system: Linux (Ubuntu)
Description:

Note that JSONPATH documentation states [1]:

> to write a backslash itself, you must write \\

It works for a backslash as long as it is not the last character in the
input string.

Simplest way to reproduce:

psql (16.3 (Ubuntu 16.3-1.pgdg22.04+1))

postgres=# select '$.field ? (@ like_regex "a\\b")'::jsonpath; -- works
jsonpath
---------------------------------
$."field"?(@ like_regex "a\\b")
(1 row)

postgres=# select '$.field ? (@ like_regex "a\\")'::jsonpath; -- does not
work
ERROR: invalid regular expression: invalid escape \ sequence
LINE 1: select '$.field ? (@ like_regex "a\\")'::jsonpath;
^

Also reproducible with functions like jsonb_path_exists(...) which
automatically cast parameters to jsonpath.

1:
/docs/current/datatype-json.html#DATATYPE-JSONPATH

On Fri, Jun 14, 2024 at 1:24 PM PG Bug reporting form <
noreply(at)postgresql(dot)org> wrote:

> The following bug has been logged on the website:
>
> Bug reference: 18510
> Logged by: Lex Vorona
> Email address: voronaam(at)gmail(dot)com
> PostgreSQL version: 16.3
> Operating system: Linux (Ubuntu)
> Description:
>
> postgres=# select '$.field ? (@ like_regex "a\\")'::jsonpath; -- does not
> work
> ERROR: invalid regular expression: invalid escape \ sequence
> LINE 1: select '$.field ? (@ like_regex "a\\")'::jsonpath;
>
>
It is working just fine. It sees both the regex and the backslash
character and then helpfully tells you that the regex you wrote is bogus
since the backslash you wrote isn't escaping anything.

If you need a literal backslash in a jsonpath string literal you need to
write four of them. Each pair leaves one \ in the regex and then \\ in a
regex is just a literally matched character.

David J.

Thank you. The bug can be closed then and I will make sure I have enough
slashes coming through. The query originates in a Java string, meaning it
will be eight trailing slashes to match.

Thanks again for a quick response.

-- Lex

On Fri, Jun 14, 2024 at 1:32 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Fri, Jun 14, 2024 at 1:24 PM PG Bug reporting form <
> noreply(at)postgresql(dot)org> wrote:
>
>> The following bug has been logged on the website:
>>
>> Bug reference: 18510
>> Logged by: Lex Vorona
>> Email address: voronaam(at)gmail(dot)com
>> PostgreSQL version: 16.3
>> Operating system: Linux (Ubuntu)
>> Description:
>>
>> postgres=# select '$.field ? (@ like_regex "a\\")'::jsonpath; -- does not
>> work
>> ERROR: invalid regular expression: invalid escape \ sequence
>> LINE 1: select '$.field ? (@ like_regex "a\\")'::jsonpath;
>>
>>
> It is working just fine. It sees both the regex and the backslash
> character and then helpfully tells you that the regex you wrote is bogus
> since the backslash you wrote isn't escaping anything.
>
> If you need a literal backslash in a jsonpath string literal you need to
> write four of them. Each pair leaves one \ in the regex and then \\ in a
> regex is just a literally matched character.
>
> David J.
>

On 2024-Jun-14, David G. Johnston wrote:

> It is working just fine. It sees both the regex and the backslash
> character and then helpfully tells you that the regex you wrote is
> bogus since the backslash you wrote isn't escaping anything.

Not really connected to this bug, but I think we should get rid of the
error that says that the end backslashes are useless. If that error
wasn't there, we would be one step closer to being able to mark the
operator for LIKE as leakproof. Right now, if you mark that operator as
leakproof and use it in a security barrier view, attackers can leak
entire strings by testing with that operator for each character one at a
time.

=# select * from secret where data like substring(data, 1, 7) escape 'r';
ERROR: LIKE pattern must not end with escape character

Here I verify that the character number 7 is an 'r'.

So this one error is the sole reason we have to mark the LIKE operator
as leaky, which is sad.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Just treat us the way you want to be treated + some extra allowance
for ignorance." (Michael Brusser)