public inbox for [email protected]
help / color / mirror / Atom feedFrom: Florents Tselai <[email protected]>
To: Alexander Korotkov <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
Date: Thu, 26 Sep 2024 15:59:51 +0300
Message-ID: <CA+v5N41ApiOdU6VyxaY0_8o=2LLmr_h20R-_am5DK0KxsV2tZg@mail.gmail.com> (raw)
In-Reply-To: <CAPpHfdtGhn_5jfLoepOScyqT+FXYB9QtV-OEprychDcMJco7mw@mail.gmail.com>
References: <CA+v5N40sJF39m0v7h=QN86zGp0CUf9F1WKasnZy9nNVj_VhCZQ@mail.gmail.com>
<[email protected]>
<CAPpHfdtGhn_5jfLoepOScyqT+FXYB9QtV-OEprychDcMJco7mw@mail.gmail.com>
On Thu, Sep 26, 2024 at 1:55 PM Alexander Korotkov <[email protected]>
wrote:
> On Thu, Sep 26, 2024 at 12:04 AM Tom Lane <[email protected]> wrote:
> > Florents Tselai <[email protected]> writes:
> > > This patch is a follow-up and generalization to [0].
> > > It adds the following jsonpath methods: lower, upper, initcap,
> l/r/btrim,
> > > replace, split_part.
> >
> > How are you going to deal with the fact that this makes jsonpath
> > operations not guaranteed immutable? (See commit cb599b9dd
> > for some context.) Those are all going to have behavior that's
> > dependent on the underlying locale.
> >
> > We have the kluge of having separate "_tz" functions to support
> > non-immutable datetime operations, but that way doesn't seem like
> > it's going to scale well to multiple sources of mutability.
>
> While inventing "_tz" functions I was thinking about jsonpath methods
> and operators defined in standard then. Now I see huge interest on
> extending that. I wonder if we can introduce a notion of flexible
> mutability? Imagine that jsonb_path_query() function (and others) has
> another function which analyzes arguments and reports mutability. If
> jsonpath argument is constant and all methods inside are safe then
> jsonb_path_query() is immutable otherwise it is stable. I was
> thinking about that back working on jsonpath, but that time problem
> seemed too limited for this kind of solution. Now, it's possibly time
> to shake off the dust from this idea. What do you think?
>
> ------
> Regards,
> Alexander Korotkov
> Supabase
>
In case you're having a deja vu, while researching this
I did come across [0] where disussing this back in 2019.
In this patch I've conveniently left jspIsMutable and jspIsMutableWalker
untouched and under the rug,
but for the few seconds I pondered over this,the best answer I came with
was
a simple heuristic to what Alexander says above:
if all elements are safe, then the whole jsp is immutable.
If we really want to tackle this and make jsonpath richer though,
I don't think we can avoid being a little more flexible/explicit wrt
mutability.
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?
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
[0]
https://www.postgresql.org/message-id/[email protected]...
[1] https://www.rfc-editor.org/rfc/rfc9535.html#name-function-extensions
[2] https://github.com/apache/age/blob/master/src/include/utils/agtype.h
view thread (39+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
In-Reply-To: <CA+v5N41ApiOdU6VyxaY0_8o=2LLmr_h20R-_am5DK0KxsV2tZg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox