> On 17 Sep 2024, at 9:40 PM, David E. Wheeler <david@justatheory.com> wrote:
>
> On Sep 16, 2024, at 18:39, Florents Tselai <florents.tselai@gmail.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
evaluatingwhether 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’tbeen 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
>
