Steps to reproduce:
SELECT get_json_string('{"order": {"id": 42}, "id": 7}', 'order.id');Expected: 42 (order.id is the documented "simple syntax" for $.order.id)
Actual: 7 — the value of the top-level id field.
The same applies everywhere jsonpaths are accepted: a routine load / stream load job with "jsonpaths" = "[\"order.id\"]" silently loads the top-level id into the target column instead of order.id — no error, no filtered row, just wrong data. A single-token path ('k2') fails as an "empty json path" instead of selecting k2.
Root cause: JsonFunctions::_get_parsed_paths supports paths without the leading $ by inserting an implicit root segment — but it continues over the first token while doing so, so the token is never parsed into the path. "order.id" becomes [root, id], and every consumer iterates from segment 1.
Affected: get_json_string/get_json_int/get_json_double on VARCHAR, jsonpaths in stream load / routine load (JSON). (json_query and the JSON type use a different parser and are not affected.)
Steps to reproduce:
Expected:
42(order.idis the documented "simple syntax" for$.order.id)Actual:
7— the value of the top-levelidfield.The same applies everywhere
jsonpathsare accepted: a routine load / stream load job with"jsonpaths" = "[\"order.id\"]"silently loads the top-levelidinto the target column instead oforder.id— no error, no filtered row, just wrong data. A single-token path ('k2') fails as an "empty json path" instead of selectingk2.Root cause:
JsonFunctions::_get_parsed_pathssupports paths without the leading$by inserting an implicit root segment — but itcontinues over the first token while doing so, so the token is never parsed into the path."order.id"becomes[root, id], and every consumer iterates from segment 1.Affected:
get_json_string/get_json_int/get_json_doubleon VARCHAR,jsonpathsin stream load / routine load (JSON). (json_queryand the JSON type use a different parser and are not affected.)