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 1qWo4b-004PPU-AD for pgsql-hackers@arkaria.postgresql.org; Fri, 18 Aug 2023 01:14:45 +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 1qWo4Z-006lPa-Ek for pgsql-hackers@arkaria.postgresql.org; Fri, 18 Aug 2023 01:14:43 +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 1qWo4Z-006lPS-4V for pgsql-hackers@lists.postgresql.org; Fri, 18 Aug 2023 01:14:43 +0000 Received: from mail-oo1-xc33.google.com ([2607:f8b0:4864:20::c33]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qWo4W-000lYT-CE for pgsql-hackers@postgresql.org; Fri, 18 Aug 2023 01:14:42 +0000 Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-56d6dfa1f3cso313429eaf.0 for ; Thu, 17 Aug 2023 18:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692321278; x=1692926078; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7TKfcSu2ocTPSTR3Vb1ADyDGywgXbkLhpRd5PTCrcTo=; b=sscaPBqjelZ7wTv6vk+7csdH6OpxCQVzvUfE2XAQmTSPPCLh6EeKltwfuIX85fBKgj toqNNgaTXDpmuGqMedzAGl+HXdlkY++f7K7tJpxl+uaA4RfqzTCNeFUCd0wZEaKM1q09 ejMGwWBa9VQkzfycTAi0incOKoWUyU+aDvz8wgBdt/TtFq1N7dKJ2Z32beixrXClYmSY Q06Xy4qbzTXbVWLeSeFDVor4T9ZEJJjdUbUEDtpIdGhOdV61TZXmz3qiLsIiFXrkfmIE ec7P6WKyQhcchbSJwwWOZDwcoclHB7lXI0YASdLXjMd5EBms2N4urywLjnAFBp3Xa3H+ wxDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692321278; x=1692926078; 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=7TKfcSu2ocTPSTR3Vb1ADyDGywgXbkLhpRd5PTCrcTo=; b=Ng6LwfLiEkD55WAzW+g0itL145xZDQ3e2ruPummid2lrbUMTv/i/yMZ8N49xt3ecgk /d4IE2+BKgWunNug9lh4bfKhT6luCQVrSoUF5SUsWlUay6UZCCnHb9aG0lYnFQ6j4hUz rRil0g9mN5bQph0IEPtpYTLfCyzr0lY50xYXoLGR6wlGdx3cJNwpHWIyCAX18QUzXP8s /E26vLd1GnUY/bc4sXUB7F1fRCvdAwGAzdY7V9h/Gzksr4j6ECHaB1LQvjZ1IOmaKksz 0gRSDhEO6CMJu0afrJLINtjWOj31G865P8nfr/5TfiKhipTq8t8XRmFl4yGB+NDuNNwg EP9g== X-Gm-Message-State: AOJu0YwNstkuXCW86/ehOyJuapvueh4l7lzjKKBEa3BqHiuM/OqA94HM zRXO0nz4h9JbuyCjIgU/+L848k2zGphP2fndZ5g= X-Google-Smtp-Source: AGHT+IHylyXjQFOcctJsydoG9uHK+rAc6FfE5kY30n1Jka7jhlwNMfufpUA17O79e3nZ/1URazAXsf6QQ2GCqb53dp8= X-Received: by 2002:a4a:2a49:0:b0:56e:468b:a4b with SMTP id x9-20020a4a2a49000000b0056e468b0a4bmr1206185oox.2.1692321278407; Thu, 17 Aug 2023 18:14:38 -0700 (PDT) MIME-Version: 1.0 References: <3507485.1691090027@sss.pgh.pa.us> <900892914fdc3f477b101d699efb40e0@anastigmatix.net> <903341.1692022214@sss.pgh.pa.us> <4b97f1a1dd9b6e45443d24870d3be698@anastigmatix.net> In-Reply-To: <4b97f1a1dd9b6e45443d24870d3be698@anastigmatix.net> From: Andy Fan Date: Fri, 18 Aug 2023 09:14:27 +0800 Message-ID: Subject: Re: Extract numeric filed in JSONB more effectively To: Chapman Flack Cc: jian he , Pavel Stehule , Tom Lane , pgsql-hackers Content-Type: multipart/alternative; boundary="000000000000a53aad06032840d1" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a53aad06032840d1 Content-Type: text/plain; charset="UTF-8" Hi Chapman, Thanks for the review! The idea of an 'internal' return type with no 'internal' parameter > was quickly and rightly shot down. Yes, it mainly breaks the type-safety system. Parser need to know the result type, so PG defines the rule like this: anyelement fn(anyment in); if the exprType(in) in the query tree is X, then PG would think fn return type X. that's why we have to have an anyelement in the input. > But it would have seemed to me > enough to address that objection by using 'internal' also in its > parameter list. I could imagine a function declared with two > 'internal' parameters, one understood to be a JsonbValue and one > understood to be a type oid, and an 'internal' result, treated in > the rewritten expression tree as binary-coercible to the desired > result. > I have some trouble understanding this. are you saying something like: internal fn(internal jsonValue, internal typeOid)? If so, would it break the type-safety system? And I'm not pretty sure the 'binary-coercible' here. is it same as the 'binary-coercible' in "timestamp is not binary coercible with timestamptz since..."? I have a strong feeling that I think I misunderstood you here. > Perhaps there are parts of that rewriting that no existing node type > can represent? > I didn't understand this as well:(:( But I have the sense that that approach was abandoned early, in > favor of the current approach using user-visible polymorphic > types, and supplying typed dummy constants for use in the > resolution of those types, with a new function introduced to create > said dummy constants, including allocation and input conversion > in the case of numeric, just so said dummy constants can be > passed into functions that have no use for them other than to > call get_fn_expr_argtype to recover the type oid, which was the > only thing needed in the first place. Yes, but if we follow the type-safety system, we can't simply input a Oid targetOid, then there are some more considerations here: a). we can't use the makeNullConst because jsonb_xxx_type is strict, so if we have NULL constant input here, the PG system will return NULL directly. b). Not only the type oid is the thing We are interested in the const.constvalue is as well since 'explain select xxxx' to access it to show it as a string. Datum(0) as the constvalue will crash in this sense. That's why makeDummyConst was introduced. > something like "assertion of > 'internal'-to-foo binary coercibility, vouched by a prosupport > function", would that be a bad thing? > I can't follow this as well. Could you provide the function prototype here? -- Best Regards Andy Fan --000000000000a53aad06032840d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chapman,=C2=A0
<= br>
Thanks for the review!

The idea of an 'internal' return type with no 'internal' pa= rameter
was quickly and rightly shot down.

Yes, it= mainly breaks the type-safety system.=C2=A0 Parser need to know
= the result type, so PG defines the rule like this:

anyelement fn(anyment in);=C2=A0

if the exprType(= in) in the query tree is X, then PG would think fn
return type X.= =C2=A0 that's why we have to have an anyelement in the
input.= =C2=A0
=C2=A0
But it would have seemed to me
enough to address that objection by using 'internal' also in its parameter list. I could imagine a function declared with two
'internal' parameters, one understood to be a JsonbValue and one understood to be a type oid, and an 'internal' result, treated in the rewritten expression tree as binary-coercible to the desired
result.

I have some trouble understandi= ng this.=C2=A0 are you saying something
like:

internal fn(internal jsonValue,=C2=A0 internal typeOid)?=C2=A0=C2=A0<= /div>

If so, would it break the type-safety system?=C2= =A0 And I'm not pretty
sure the 'binary-coercible' he= re.=C2=A0 is it same as the 'binary-coercible'
in "t= imestamp is not binary coercible with timestamptz since..."?
I have a strong feeling that I think I misunderstood you here.=C2=A0
=
=C2=A0
Perhaps = there are parts of that rewriting that no existing node type
can represent?=C2=A0
=C2=A0
I didn't und= erstand this as well:(:(=C2=A0

But I have the sense that that approach was abandoned early, in
favor of the current approach using user-visible polymorphic
types, and supplying typed dummy constants for use in the
resolution of those types, with a new function introduced to create
said dummy constants, including allocation and input conversion
in the case of numeric, just so said dummy constants can be
passed into functions that have no use for them other than to
call get_fn_expr_argtype to recover the type oid, which was the
only thing needed in the first place.

Yes,= =C2=A0 but if we follow the type-safety system, we can't simply input
a Oid targetOid, then there are some more considerations here:=C2= =A0=C2=A0
a).=C2=A0 we can't use the makeNullConst because js= onb_xxx_type is
strict,=C2=A0 so if we have NULL constant input h= ere,=C2=A0 the PG system
will return NULL directly.=C2=A0 b).=C2= =A0 Not only the type oid is the thing
We are interested in the= =C2=A0=C2=A0const.constvalue is as well since=C2=A0
'explain = select xxxx'=C2=A0 to access it to show it as a string.=C2=A0=C2=A0
Datum(0) as the constvalue will crash in this sense.=C2=A0 That'= s why
makeDummyConst was introduced.=C2=A0
=C2=A0
=
something like "asse= rtion of
'internal'-to-foo binary coercibility, vouched by a prosupport
function", would that be a bad thing?

<= /div>
I can't follow this as well.=C2=A0 Could you provide the func= tion prototype
here?=C2=A0

--
Best Regards
Andy Fan
--000000000000a53aad06032840d1--