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

On May 25, 2025, at 00:16, Florents Tselai <florents(dot)tselai(at)gmail(dot)com> wrote:

> 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.

Oh. They have been organized by length; I didn’t notice they were also alphabetical.

> But you may be onto something with the split_part thing.

Yes, I think it would be best if the grammar was a bit stricter --- and therefore more self-explanatory --- by making the args closer to what the functions actually expect.

>> 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()…'

Yes. Each of the existing methods has well-defined rules for what types of values they operate on, and many accept multiple types. Looking again, though, it appears that all the date/time methods operate only on strings, so I think you’re correct to follow that precedent and people can use `.string()` if they need it. We can also loosen it up later if use cases demand it.

>> 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

Fair enough.

Best,

David