All array element accessors require non-array items to be wrapped

[pstef]

Both SELECT JSON_QUERY(jsonb '{}', '{"a":"b"}[*]'); and SELECT JSON_QUERY(jsonb '{}', '{}["bread"]'); should return values (the latter query should return a null value).

[pstef]

This is a separate pull request, because I discovered this issue the next day I created PR #3. I didn't unify the two commits by creating a new PR, because this change could use some discussion.

My main concern is that '{}["bread"]'::jsonpath is allowed at the parsing level. The technical report I'm using to learn the SQL/JSON path language specifically says:

The subscripts can be specified in either of two forms:

1. A single numeric value.
2. A range between two numeric values (inclusive) indicated by the keyword to .

and specifically forbids strings:

In both strict and lax mode, non-numeric subscripts such as $["hello"] are an error.

On the other hand, the BNF they give just above the paragraph I selectively quoted says that JSON array accessor is a bracketed JSON subscript list which if a list of JSON path wff - and JSON path wff appears to be the entire language specification, excluding the mode name.

Even if you decide to allow strings to be elements of array subscripts, I'm not sure why unquoted character sequences like in the following example are allowed:
SELECT JSON_QUERY(jsonb '{}', '{}[bread]');

[glukhovn]

I agree that unquoted string literals should not be allowed in jsonpath grammar. Now they are not distinguished from quoted literals in grammar, so I'll have to fix this issue.

Object subscripting with string subscripts is our extension (see commit 63113dc where processing of jpiIndexArray had been moved into recursiveExecuteNoUnwrap()).

Here are examples showing differences in behavior between lax and strict mode:

postgres=# SELECT JSON_QUERY(jsonb '[]', 'strict $[0]' ERROR ON EMPTY ERROR ON ERROR);
ERROR: Invalid SQL/JSON subscript
postgres=# SELECT JSON_QUERY(jsonb '[]', 'lax $[5]' ERROR ON EMPTY ERROR ON ERROR);
ERROR: no SQL/JSON item

postgres=# SELECT JSON_QUERY(jsonb '{}', 'strict $[5]' ERROR ON EMPTY ERROR ON ERROR);
ERROR: Invalid SQL/JSON subscript
postgres=# SELECT JSON_QUERY(jsonb '{}', 'lax $[5]' ERROR ON EMPTY ERROR ON ERROR);
ERROR: no SQL/JSON item
postgres=# SELECT JSON_QUERY(jsonb '{}', 'lax $[0]' ERROR ON EMPTY ERROR ON ERROR);
?column?
----------
{}
(1 row)

postgres=# SELECT JSON_QUERY(jsonb '{"a": 1}', 'lax $["b"]' ERROR ON EMPTY ERROR ON ERROR);
ERROR: no SQL/JSON item
postgres=# SELECT JSON_QUERY(jsonb '{"a": 1}', 'strict $["b"]' ERROR ON EMPTY ERROR ON ERROR);
ERROR: SQL/JSON member not found
postgres=# SELECT JSON_QUERY(jsonb '{"a": 1}', '$["a"]' ERROR ON EMPTY ERROR ON ERROR);
?column?
----------
1
(1 row)

[pstef]

This is a separate pull request, because I discovered this issue the next day I created PR #3.

I meant PR #2 there.

Object subscripting with string subscripts is our extension

I see. This should be documented somewhere.

I guess this PR boils down to "SELECT JSON_QUERY(jsonb '{}', '{}["bread"]'); shouldn't segfault".