Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\))
Subject: Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim,
 replace, split_part
From: Florents Tselai <florents.tselai@gmail.com>
In-Reply-To: <73C52BC6-E708-43CF-A79B-AB22AEDEC8A7@justatheory.com>
Date: Fri, 27 Sep 2024 13:28:21 +0300
Cc: Alexander Korotkov <aekorotkov@gmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>,
 pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA435DAF-B81C-4A3A-B0DE-9F63812644A8@gmail.com>
References: <CA+v5N40sJF39m0v7h=QN86zGp0CUf9F1WKasnZy9nNVj_VhCZQ@mail.gmail.com>
 <145894.1727298237@sss.pgh.pa.us>
 <CAPpHfdtGhn_5jfLoepOScyqT+FXYB9QtV-OEprychDcMJco7mw@mail.gmail.com>
 <CA+v5N41ApiOdU6VyxaY0_8o=2LLmr_h20R-_am5DK0KxsV2tZg@mail.gmail.com>
 <73C52BC6-E708-43CF-A79B-AB22AEDEC8A7@justatheory.com>
To: "David E. Wheeler" <david@justatheory.com>
Archived-At: <https://www.postgresql.org/message-id/EA435DAF-B81C-4A3A-B0DE-9F63812644A8%40gmail.com>
Precedence: bulk


> On 27 Sep 2024, at 12:45=E2=80=AFPM, David E. Wheeler =
<david@justatheory.com> wrote:
>=20
> On Sep 26, 2024, at 13:59, Florents Tselai <florents.tselai@gmail.com> =
wrote:
>=20
>> Speaking of extensible: the jsonpath standard does mention function =
extensions [1] ,
>> so it looks like we're covered by the standard, and the mutability =
aspect is an implementation detail. No?
>=20
> That=E2=80=99s not the standard used for Postgres jsonpath. Postgres =
follows the SQL/JSON standard in the SQL standard, which is not publicly =
available, but a few people on the list have copies they=E2=80=99ve =
purchased and so could provide some context.
>=20
> In a previous post I wondered if the SQL standard had some facility =
for function extensions, but I suspect not. Maybe in the next iteration?
>=20
>> And having said that, the whole jsonb/jsonpath parser/executor =
infrastructure is extremely powerful
>> and kinda under-utilized if we use it "only" for jsonpath.
>> Tbh, I can see it supporting more specific DSLs and even offering =
hooks for extensions.
>> And I know for certain I'm not the only one thinking about this.
>> See [2] for example where they've lifted, shifted and renamed the =
jsonb/jsonpath infra to build a separate language for graphs
>=20
> I=E2=80=99m all for extensibility, though jsonpath does need to =
continue to comply with the SQL standard. Do you have some idea of the =
sorts of hooks that would allow extension authors to use some of that =
underlying capability?

Re-tracing what I had to do

1. Define a new JsonPathItemType jpiMyExtType and map it to a =
JsonPathKeyword
2. Add a new JsonPathKeyword and make the lexer and parser aware of =
that,
3. Tell the main executor executeItemOptUnwrapTarget what to do when the =
new type is matched.

I think 1, 2 are the trickiest because they require hooks to  =
jsonpath_scan.l and parser jsonpath_gram.y=20

3. is the meat of a potential hook, which would be something like=20
extern JsonPathExecResult executeOnMyJsonpathItem(JsonPathExecContext =
*cxt, JsonbValue *jb, JsonValueList *found);
This should be called by the main executor executeItemOptUnwrapTarget =
when it encounters case jpiMyExtType

It looks like quite an endeavor, to be honest.=