> On 25 May 2025, at 1:01 AM, David E. Wheeler <david@justatheory.com> wrote:
>
> On May 24, 2025, at 17:55, David E. Wheeler <david@justatheory.com> wrote:
>
>> And now I see my patch broke the grammar because I left some of my fiddling in there. Apologies. Here’s an updated
patchwith the updated keyword map, too.
>
> No, really :sigh:
>
> D
>
> <v5-0001-Add-additional-jsonpath-string-methods.patch>
The most important problem in jsonpath_scan.l now is the fact that I broke the alphabetical ordering of keywords in v2
,
and you followed that too.
> I'm curious why you added the `arg0` and `arg1` fields to the `method_args` union. Is there some reason that the
existing`left` and `right` fields wouldn't work?
The left-right ended-up being more of a brain teaser to work with in jsonpath_exec.
Until before these methods, the opt_datetime_template was the only argument passed in existing jsonpath functions,
So initially I used that as a template to add to the scann-parser infra,
but then realized it may make morese sense to have a way to access indexed-args.
IIRC, with an eye in the future I found it much more convenient - less of the to work with indexed-args.
I should have gone back and use them for *TRIM_P too
But you may be onto something with the split_part thing.
> The existing string() method operates on a "JSON boolean, number, string, or datetime"; should these functions also
operateon all those data types?
You mean implicitely conversion to string first?
I don’t think so: I’d expect to work like ‘$…string().replace()…'
> I'm not sure how well these functions comply with the SQL spec.
The fact that Peter hasn’t raized this as an issue, makes me think it's not one
