| From: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
|---|---|
| To: | 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-17 19:16:57 |
| Message-ID: | 185BF814-9225-46DB-B1A1-6468CF2C8B63@justatheory.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
I don’t have a strong feeling about what should be added that’s not in the spec; my main interest is not having to constantly sync my port[2]. I’m already behind, and’t just been a couple months! 😂
Best,
David
[1]: https://www.rfc-editor.org/rfc/rfc9535.html#name-function-extensions
[2]: https://github.com/theory/sqljson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2024-09-17 19:22:21 | miscellaneous pg_upgrade cleanup |
| Previous Message | Florents Tselai | 2024-09-17 19:03:17 | Re: [PATCH] WIP: replace method for jsonpath |