> On 18 Sep 2024, at 11:23 AM, Peter Eisentraut <pe...@eisentraut.org> wrote: > > On 17.09.24 21:16, David E. Wheeler wrote: >> On Sep 17, 2024, at 15:03, Florents Tselai <florents.tse...@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? >
Well, we can. A couple of weeks ago, I discovered transform_jsonb_string_values, which is already available in jsonfuncs.h and that gave me the idea for this extension https://github.com/Florents-Tselai/jsonb_apply It does exactly what you’re saying: searches for a suitable pg_proc in the catalog, and directly applies it. select jsonb_apply('{ "id": 1, "name": "John", "messages": [ "hello" ] }', 'replace', 'hello', 'bye’); select jsonb_filter_apply('{ "id": 1, "name": "John", "messages": [ "hello" ] }', '{messages}', 'md5’); But, I don't know… jsonb_apply? That seemed “too fancy”/LISPy for standard Postgres. Now that you mention it, though, there’s an alternative of tweaking the grammar and calling the suitable text proc.