Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sto6p-001nTh-1a for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Sep 2024 13:00:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sto6o-00831O-Eg for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Sep 2024 13:00:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sto6n-00831G-W8 for pgsql-hackers@lists.postgresql.org; Thu, 26 Sep 2024 13:00:38 +0000 Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sto6h-0019tt-5J for pgsql-hackers@lists.postgresql.org; Thu, 26 Sep 2024 13:00:36 +0000 Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-207115e3056so7249535ad.2 for ; Thu, 26 Sep 2024 06:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727355630; x=1727960430; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=flzJnAtfjsANqAU06RdmTMPpFi7XtFaxYPxgqyV8qxE=; b=YcG3HujCDHPeWtmTYxfEbiOt1HTljUborU84Upnyf4snMv0C6S2PV9YCEVRekaHvCp RGqtF9kM8aj1bR1B62kgFTa60AORqncjFodSE2xpBuHU5XgswNm8agY1yHBKIYMRGqlB 4q5zoZn4zxqsVFXVFumaNvavCmtFwoGkx3RPUBgjTxUXCDbQGSXR2qtI7ju3Q6+k6Mpy 8BnLVqkpyKUe3K5bgiBeLEK6Eaq4pKaBGoZ+chetPtMVkWQKNIbbWlqZ23EJthJs9Pbn 1dZMO5o5MWJRZGUzwqTXpO3QxuGTWG6N9ZJ35S/5CnAMSaxU4klLvKBY19XhQt6ia7oA f3ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727355630; x=1727960430; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=flzJnAtfjsANqAU06RdmTMPpFi7XtFaxYPxgqyV8qxE=; b=XRBBOEoRwl+LmKD6NudnOvl8RaBP2kqWYpVDaiLP2KgBnBNhaE8xFvuwZMY/wgbO+5 13xrE00LAwxMRM27RhR8FOQAUDDUGFuP9//LAN9H5kq+v7uOaqSmmXBW8hdGz83tDpU9 CcBIAWIlWWkSFglza3AZ4GIMGIrU4DaHM3IhMU24Pccl5E5aXw2Gzg/pw6XY23RQom9/ vCuHSRbeMA03mN7ZzkLoa+4uJVKI9RlqDsw8HtOlOAogGUC6nLi4SVB8yGHWXE56xhN6 BisLYA3uyZIn7OyhE48LqrYN277Zh6dNg9L2+VKCsQXA4G4Rfg5nHO2SvyW1zIMKX7UA NLVA== X-Forwarded-Encrypted: i=1; AJvYcCVFcNhSOAzfmzciW8ArUivyFMWOrwOCzCW/gdmdYm5jLKxqAmDyj76sSo1k6vUhoErmbbCrWAAe8ZkfkSb1@lists.postgresql.org X-Gm-Message-State: AOJu0Ywn8aS2uv0eSfHrpiXutjRaZMj1mOgB+EQC8bYngP3VAjfwtiJL lO19BgY6i2csOuCg9OgvWl+7PZNfrwahauvKLfW3OzpCcN0lP1yTNAhTdW8L/eIL7YhVRKaYH+N RjHPsyqOSHc2FuD0sYTjf8CuMcSGqg5qOZA0M5g== X-Google-Smtp-Source: AGHT+IGBkWrYLt3gc/pkGTccI59n/ZHcOETr0db0VJx2YFvoRFbLx2nNJH3uQV0GlixgTvA4SLqSxzd/gUrLjjkfRu4= X-Received: by 2002:a17:902:fc85:b0:205:861c:5c4a with SMTP id d9443c01a7336-20afc67718bmr70045895ad.60.1727355629065; Thu, 26 Sep 2024 06:00:29 -0700 (PDT) MIME-Version: 1.0 References: <145894.1727298237@sss.pgh.pa.us> In-Reply-To: From: Florents Tselai Date: Thu, 26 Sep 2024 15:59:51 +0300 Message-ID: Subject: Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part To: Alexander Korotkov Cc: Tom Lane , pgsql-hackers Content-Type: multipart/alternative; boundary="000000000000abe3cf06230552dc" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000abe3cf06230552dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 26, 2024 at 1:55=E2=80=AFPM Alexander Korotkov wrote: > On Thu, Sep 26, 2024 at 12:04=E2=80=AFAM Tom Lane wro= te: > > Florents Tselai 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/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56= drH+_Rv2rNRqfg@mail.gmail.com [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 --000000000000abe3cf06230552dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=


On Thu, Sep 26, 2024 at 1:55= =E2=80=AFPM Alexander Korotkov <= aekorotkov@gmail.com> wrote:
On Thu, Sep 2= 6, 2024 at 12:04=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Florents Tselai <florents.tselai@gmail.com> writes:
> > This patch is a follow-up and generalization to [0].
> > It adds the following jsonpath methods:=C2=A0 lower, upper, initc= ap, l/r/btrim,
> > replace, split_part.
>
> How are you going to deal with the fact that this makes jsonpath
> operations not guaranteed immutable?=C2=A0 (See commit cb599b9dd
> for some context.)=C2=A0 Those are all going to have behavior that'= ;s
> dependent on the underlying locale.
>
> We have the kluge of having separate "_tz" functions to supp= ort
> non-immutable datetime operations, but that way doesn't seem like<= br> > it's going to scale well to multiple sources of mutability.

While inventing "_tz" functions I was thinking about jsonpath met= hods
and operators defined in standard then.=C2=A0 Now I see huge interest on extending that.=C2=A0 I wonder if we can introduce a notion of flexible
mutability?=C2=A0 Imagine that jsonb_path_query() function (and others) has=
another function which analyzes arguments and reports mutability.=C2=A0 If<= br> jsonpath argument is constant and all methods inside are safe then
jsonb_path_query() is immutable otherwise it is stable.=C2=A0 I was
thinking about that back working on jsonpath, but that time problem
seemed too limited for this kind of solution.=C2=A0 Now, it's possibly = time
to shake off the dust from this idea.=C2=A0 What do you think?

------
Regards,
Alexander Korotkov
Supabase

In case you're having a de= ja vu, while researching this =C2=A0
I did come across [0] wh= ere disussing this back in 2019.

In this patch= I've conveniently left jspIsMutable and jspIsMutableWalker untouched a= nd under the rug,
but for the few seconds I pondered over this,th= e best answer I came with was=C2=A0
a simple heuristic to what Al= exander 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,=C2=A0
I don't think we can avoi= d being a little more flexible/explicit wrt mutability.

Speaking of extensible: the jsonpath standard does mention funct= ion 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 infr= astructure is extremely powerful
and kinda under-utilized if = we use it "only" for jsonpath.
Tbh, I can see it suppor= ting more specific DSLs and even offering hooks for extensions.
A= nd 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 js= onb/jsonpath infra to build a separate language=C2=A0for graphs
<= br>
--000000000000abe3cf06230552dc--