On May 25, 2025, at 00:16, Florents Tselai <florents.tse...@gmail.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
signature.asc
Description: Message signed with OpenPGP
