From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Florents Tselai <florents(dot)tselai(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] WIP: replace method for jsonpath |
Date: | 2024-09-18 08:23:22 |
Message-ID: | f9b2da4e-a252-4d47-b6ff-98d777cce6fa@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 17.09.24 21:16, David E. Wheeler wrote:
> On Sep 17, 2024, at 15:03, Florents Tselai <florents(dot)tselai(at)gmail(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2024-09-18 08:23:52 | Re: information_schema.view attgenerated |
Previous Message | Peter Eisentraut | 2024-09-18 08:09:38 | Re: information_schema.view attgenerated |