Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part

> 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 patch with 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 operate on 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