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 1qRZIu-002Cl6-Pr for pgsql-hackers@arkaria.postgresql.org; Thu, 03 Aug 2023 14:27:53 +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 1qRZIt-00E5TN-9d for pgsql-hackers@arkaria.postgresql.org; Thu, 03 Aug 2023 14:27:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qRZIt-00E5TF-08 for pgsql-hackers@lists.postgresql.org; Thu, 03 Aug 2023 14:27:51 +0000 Received: from mail-ot1-x329.google.com ([2607:f8b0:4864:20::329]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qRZIr-000M5l-Ag for pgsql-hackers@postgresql.org; Thu, 03 Aug 2023 14:27:50 +0000 Received: by mail-ot1-x329.google.com with SMTP id 46e09a7af769-6b9ec15e014so1019860a34.0 for ; Thu, 03 Aug 2023 07:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691072867; x=1691677667; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RDvHwe0hy579nLhS/rdWFnGbNvraxIlnE4zPSrhJLW0=; b=a7idoKagnIQkXmKh0Qrol/L00ixbt6jHM51etYrbM/rl5yYfgEAqdYAiQIDTG6cPTH s2hdgky17ITrCxossMGC9hYbJX0RBaHSkaUMF54T0AvOKZo/Xr7KWzSHTBrN3eqrKG0H YFPUboBFT0sduEOoFraBElak/a36fCI4SZBOMhVUye5OQIdFkYnPEkSSh1Cjazl4IcHq Zsp5q1cZm8//o4kMGt49iYSwtReg5lrrt1YZG1OvwY1ixLbDaCmCPYbql7Be2O63LrtB AUzjnPuKjewI67IC0+EdVTaeaATR8RgsX3+cU4kyaRQnSpz2ewTgvTgNQAI5WvwxyF6q Mtww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691072867; x=1691677667; 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=RDvHwe0hy579nLhS/rdWFnGbNvraxIlnE4zPSrhJLW0=; b=ivY+fVXBI5EMg6ypAUW0LCTVVVU7fQzwTkB/U2t6laKYSJdqn3b094i0S5x3Em1qMc uu/YTBIfrNtg72gkqSq1RwxYkrrSmwIsE2EuJCEw/foaTu9ELneHrRR63OxKLhvJozUh aVqjw7/m+h4gIpB7m7+5+01MnvP4bjEU4vZnTU6DbBhnAsSzmPQaFWr1ZLkMMUMzQhZk syD7hbqdFhQ3rL/aDWRIaHzNawsY9stfbKr2A/NqUdx/Cqf7fVRc68ejDqgYXe+1sBrD GnJfnb5o6Q3JzZlpnaKwTGBRBrrdDkgSEUbYEvjUn7RqfS4C8QrGRnOlXa/T+x5GPAUM MY+w== X-Gm-Message-State: ABy/qLacI2mR+DB9IKM79e/zxDBv5gHGme8ViJSQN3DeYoEndXG0WzV7 SbSSRHYgzKpmSYbVIxNSGHtoLtyVH/dyp/LpeAfeDe+I X-Google-Smtp-Source: APBJJlH82UD7fJmtUkaKcR3Vm5XzasgrFSAKfD0w6BFa60OMA+WprRGwO3mQ+DAFy3Y3mPTBnjojf65K6CVB/H4BmXM= X-Received: by 2002:a05:6871:98:b0:1ba:bb13:d007 with SMTP id u24-20020a056871009800b001babb13d007mr26051095oaa.5.1691072866965; Thu, 03 Aug 2023 07:27:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Fan Date: Thu, 3 Aug 2023 22:27:34 +0800 Message-ID: Subject: Re: Extract numeric filed in JSONB more effectively To: Pavel Stehule Cc: jian he , pgsql-hackers Content-Type: multipart/alternative; boundary="000000000000865b27060205955c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000865b27060205955c Content-Type: text/plain; charset="UTF-8" Hi: > If you use explicit cast, then the code should not be hard, in the > rewrite stage all information should be known. > Can you point to me where the code is for the XML stuff? I thought this is a bad idea but I may accept it if some existing code does such a thing already. "such thing" is typeA:typeB is converted something else but user can't find out an entry in pg_cast for typeA to typeB. > It would be cool but still I didn't see a way to do that without making >> something else complex. >> > > The custom @-> operator you can implement in your own custom extension. > Builtin solutions should be generic as it is possible. > I agree, but actually I think there is no clean way to do it, at least I dislike the conversion of typeA to typeB in a cast syntax but there is no entry in pg_cast for it. Are you saying something like this or I misunderstood you? > -- Best Regards Andy Fan --000000000000865b27060205955c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi:=C2=A0


=C2=A0If you use explicit cast, then the code should not be hard, in the r= ewrite stage all information should be known.

Can you point to me where the code is for the XML stuf= f?=C2=A0 I thought
this is a bad idea but I may accept it if some= existing code does
such a thing already.=C2=A0 =C2=A0"such = thing"=C2=A0 is=C2=A0 typeA:typeB is
converted something els= e but user can't find out an entry in
pg_cast for typeA to ty= peB.=C2=A0
=C2=A0
It would be cool but still I didn't see a way to do that without makin= g
something else complex.=C2=A0

=C2=A0The custom @-> operator you can=20 implement in your own custom extension. Builtin solutions should be=20 generic as it is possible.

I agree, but actually I think there is no clean way to do it, at least I<= /div>
dislike the conversion of=C2=A0typeA to typeB in a cast syntax=C2= =A0but there
is no entry in pg_cast for it.=C2=A0 Are you saying = something like this=C2=A0
or I misunderstood you?=C2=A0


--
Best Regards
Andy Fan
--000000000000865b27060205955c--