Re: [PATCH] WIP: replace method for jsonpath

On 2024-09-18 We 4:23 AM, Peter Eisentraut wrote:
> On 17.09.24 21:16, David E. Wheeler wrote:
>> On Sep 17, 2024, at 15:03, Florents Tselai 
>> <florents.tselai@gmail.com> wrote:
>>
>>> 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.
>>
>> Yeah, it got me thinking about the RFC-9535 JSONPath "Function 
>> Extension" feature[1], which allows users to add functions. Would be 
>> cool to have a way to register jsonpath functions somehow, but I 
>> would imagine it’d need quite a bit of specification similar to 
>> RFC-9535. Wouldn’t surprise me to see something like that appear in a 
>> future version of the spec, with an interface something like CREATE 
>> OPERATOR.
>
> Why can't we "just" call any suitable pg_proc-registered function from 
> JSON path?  The proposed patch routes the example 
> '$.replace("hello","bye")' internally to the internal implementation 
> of the SQL function replace(..., 'hello', 'bye'). Why can't we do this 
> automatically for any function call in a JSON path expression?
>
>
>

That might work. The thing that bothers me about the original proposal 
is this: what if we add a new non-spec jsonpath method and then a new 
version of the spec adds a method with the same name, but not compatible 
with our method? We'll be in a nasty place. At the very least I think we 
need to try hard to avoid that. Maybe we should prefix non-spec method 
names with "pg_", or maybe use an initial capital letter.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com