Re: [PATCH] WIP: replace method for jsonpath

> On 17 Sep 2024, at 9:40 PM, David E. Wheeler <david(at)justatheory(dot)com> wrote:
>
> On Sep 16, 2024, at 18:39, Florents Tselai <florents(dot)tselai(at)gmail(dot)com> wrote:
>
>> Here’s an updated version of this patch.
>
> Oh, nice function.
>
> But a broader question for hackers: Is replace() specified in the SQL/JSON spec? If not, what’s the process for evaluating whether or not to add features not specified by the spec?

That’s the first argument I was expecting, and it’s a valid one.

From a user’s perspective the answer is:
Why not?
The more text-processing facilities I have in jsonb,
The less back-and-forth-parentheses-fu I do,
The easier my life is.

From a PG gatekeeping it’s a more complicated issue.

It’s not part of the spec,
But I think the jsonb infrastructure in PG is really powerful already and we can built on it,
And can evolve into a superset DSL of jsonpath.

For example, apache/age have lift-and-shifted this infra and built another DSL (cypher) on top of it.

>
>> As a future note:
>> It’s worth noting that both this newly added jspItem and other ones like (jpiDecimal, jpiString)
>> use jspGetRightArg and jspGetLeftArg.
>> left and right can be confusing if more complex methods are added in the future.
>> i.e. jsonpath methods with nargs>=3 .
>> I was wondering if we’d like something like JSP_GETARG(n)
>
> So far I think we have only functions defined by the spec, which tend to be unary or binary, so left and right haven’t been an issue.

If the answer to the Q above is: “we stick to the spec” then there’s no thinking about this.

But tbh, I’ve already started experimenting with other text methods in text $.strip() / trim() / upper() / lower() etc.

Fallback scenario: make this an extension, but in a first pass I didn’t find any convenient hooks.
One has to create a whole new scanner, grammar etc.

>
> Best,
>
> David
>