Re: Q: Escapes in jsonpath Idents - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Q: Escapes in jsonpath Idents
Date
Msg-id 8c6b8172-d7bd-4247-810d-1d0a35e01590@eisentraut.org
Whole thread Raw
In response to Re: Q: Escapes in jsonpath Idents  (Erik Wienhold <ewie@ewie.name>)
Responses Re: Q: Escapes in jsonpath Idents
List pgsql-hackers
On 17.03.24 20:12, Erik Wienhold wrote:
> Mentioning JSON and \v in the same sentence is wrong: JavaScript allows
> that escape in strings but JSON doesn't.  I think the easiest is to just
> replace "JSON" with "JavaScript" in that sentence to make it right.  The
> paragraph also already says "embedded string literals follow JavaScript/
> ECMAScript conventions", so mentioning JSON seems unnecessary to me.
> 
> The last sentence also mentions backslash escapes \xNN and \u{N...} as
> deviations from JSON when in fact those are valid escape sequences from
> ECMA-262:https://262.ecma-international.org/#prod-HexEscapeSequence
> 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.

I have committed this patch, and backpatched it, as a bug fix, because 
the existing description was wrong.  To keep the patch minimal for 
backpatching, I didn't do the conversion to a list.  I'm not sure I like 
that anyway, because it tends to draw more attention to that part over 
the surrounding parts, which didn't seem appropriate in this case.  But 
anyway, if you have any more non-bug-fix editing in this area, which 
would then target PG18, please send more patches.




pgsql-hackers by date:

Previous
From: "Anton A. Melnikov"
Date:
Subject: Re: Use XLOG_CONTROL_FILE macro everywhere?
Next
From: Yugo NAGATA
Date:
Subject: Re: minor error message inconsistency in make_pathkey_from_sortinfo