On Mar 17, 2024, at 15:12, Erik Wienhold <ewie@ewie.name> wrote:
> Hi David,
Hey Erik. Thanks for the detailed reply and patch!
> So I think it makes sense to reword the entire backslash part of the
> paragraph and remove references to JSON entirely. The attached patch
> does that and also formats the backslash escapes as a bulleted list for
> readability.
Ah, it’s JavaScript format, not JSON! This does clarify things quite nicely, thank you. Happy to add my review once
it’sin a commit fest.
> The first case ($.$foo) is in line with the restriction on member
> accessors that you quoted first.
Huh, that’s now how I read it. Here it is again:
>> Member accessor that returns an object member with the specified
>> key. If the key name matches some named variable starting with $ or
>> does not meet the JavaScript rules for an identifier, it must be
>> enclosed in double quotes to make it a string literal.
Note that in my example `$foo` does not match a variable. I mean it looks like a variable, but none is used here. I
guessit’s being conservative because it might be used in one of the functions, like jsonb_path_exists(), to which
variablesmight be passed.
> The error message 'syntax error at or near "$oo" of jsonpath input' for
> the second case ($.f$oo), however, looks as if the scanner identifies
> '$oo' as a variable instead of contiuing the scan of identifier (f$oo)
> for the member accessor. Looks like a bug to me because a variable
> doesn't even make sense in that place.
Right. Maybe the docs should be updated to say that a literal dollar sign isn’t supported in identifiers, unlike in
JavaScript,except through escapes like this:
> What works though, besides double quoting, is escaping the dollar sign:
>
> regress=# select '$.\u0024foo'::jsonpath;
> jsonpath
> ----------
> $."$foo"
> (1 row)
>
> And we've come full circle :)
🎉
Best,
David