MIME-Version: 1.0
References: 
 <CAM2+6=V1euSMRnYPv7s7JCndFk_3rfmaSny6So2+VJs2Xxd6Hw@mail.gmail.com>
 <20240129.121200.235012930453045390.horikyota.ntt@gmail.com>
 <1678192.1706500022@sss.pgh.pa.us>
 <20240129.141240.1988354480093375317.horikyota.ntt@gmail.com>
 <1691834.1706506402@sss.pgh.pa.us>
In-Reply-To: <1691834.1706506402@sss.pgh.pa.us>
From: Jeevan Chalke <jeevan.chalke@enterprisedb.com>
Date: Tue, 30 Jan 2024 13:46:17 +0530
Message-ID: 
 <CAM2+6=XKs_pAw9in6=h-RUy9i58km0vAwmoGRcWe4QrF5ZVM0A@mail.gmail.com>
Subject: Re: More new SQL/JSON item methods
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, andrew@dunslane.net,
 peter@eisentraut.org,
	pgsql-hackers@lists.postgresql.org
Content-Type: multipart/mixed; boundary="000000000000a0d1c40610256287"
Archived-At: 
 <https://www.postgresql.org/message-id/CAM2%2B6%3DXKs_pAw9in6%3Dh-RUy9i58km0vAwmoGRcWe4QrF5ZVM0A%40mail.gmail.com>
Precedence: bulk

--000000000000a0d1c40610256287
Content-Type: multipart/alternative; boundary="000000000000a0d1c20610256285"

--000000000000a0d1c20610256285
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 29, 2024 at 11:03=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote=
:

> Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> > Having said that, I'm a bit concerned about the case where an overly
> > long string is given there. However, considering that we already have
> > "invalid input syntax for type xxx: %x" messages (including for the
> > numeric), this concern might be unnecessary.
>
> Yeah, we have not worried about that in the past.
>
> > Another concern is that the input value is already a numeric, not a
> > string. This situation occurs when the input is NaN of +-Inf. Although
> > numeric_out could be used, it might cause another error. Therefore,
> > simply writing out as "argument NaN and Infinity.." would be better.
>
> Oh!  I'd assumed that we were discussing a string that we'd failed to
> convert to numeric.  If the input is already numeric, then either
> the error is unreachable or what we're really doing is rejecting
> special values such as NaN on policy grounds.  I would ask first
> if that policy is sane at all.  (I'd lean to "not" --- if we allow
> it in the input JSON, why not in the output?)  If it is sane, the
> error message needs to be far more specific.
>
>                         regards, tom lane
>

*Consistent error message related to type:*

Agree that the number is not a PostgreSQL type and needs a change. As Tom
suggested, we can say "type numeric" here. However, I have seen two
variants of error messages here: (1) When the input is numeric and (2) when
the input is string. For first, we have error messages like:
numeric argument of jsonpath item method .%s() is out of range for type
double precision

and for the second, it is like:
string argument of jsonpath item method .%s() is not a valid representation
of a double precision number

The second form says "double precision number". So, in the decimal/number
case, should we use "numeric number" and then similarly "big integer
number"?

What if we use phrases like "for type double precision" at both places,
like:
numeric argument of jsonpath item method .%s() is out of range for type
double precision
string argument of jsonpath item method .%s() is not a valid representation
for type double precision

With this, the rest will be like:
for type numeric
for type bigint
for type integer

Suggestions?

---

*Showing input string in the error message:*

argument "...input string here..." of jsonpath item method .%s() is out of
range for type numeric

If we add the input string in the error, then for some errors, it will be
too big, for example:

-ERROR:  numeric argument of jsonpath item method .double() is out of range
for type double precision
+ERROR:  argument
"10000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000"
of jsonpath item method .double() is out of range for type double precision

Also, for non-string input, we need to convert numeric to string just for
the error message, which seems overkill.

On another note, irrespective of these changes, is it good to show the
given input in the error messages? Error messages are logged and may leak
some details.

I think the existing way seems ok.

---

*NaN and Infinity restrictions:*

I am not sure why NaN and Infinity are not allowed in conversion to double
precision (.double() method). I have used the same restriction for
.decimal() and .number(). However, as you said, we should have error
messages more specific. I tried that in the attached patch; please have
your views. I have the following wordings for that error message:
"NaN or Infinity is not allowed for jsonpath item method .%s()"

Suggestions...


Thanks
--=20
Jeevan Chalke

*Principal, ManagerProduct Development*


edbpostgres.com

--000000000000a0d1c20610256285
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 29, 2024 at 11:03=E2=80=
=AFAM Tom Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ky=
otaro Horiguchi &lt;<a href=3D"mailto:horikyota.ntt@gmail.com" target=3D"_b=
lank">horikyota.ntt@gmail.com</a>&gt; writes:<br>
&gt; Having said that, I&#39;m a bit concerned about the case where an over=
ly<br>
&gt; long string is given there. However, considering that we already have<=
br>
&gt; &quot;invalid input syntax for type xxx: %x&quot; messages (including =
for the<br>
&gt; numeric), this concern might be unnecessary.<br>
<br>
Yeah, we have not worried about that in the past.<br>
<br>
&gt; Another concern is that the input value is already a numeric, not a<br=
>
&gt; string. This situation occurs when the input is NaN of +-Inf. Although=
<br>
&gt; numeric_out could be used, it might cause another error. Therefore,<br=
>
&gt; simply writing out as &quot;argument NaN and Infinity..&quot; would be=
 better.<br>
<br>
Oh!=C2=A0 I&#39;d assumed that we were discussing a string that we&#39;d fa=
iled to<br>
convert to numeric.=C2=A0 If the input is already numeric, then either<br>
the error is unreachable or what we&#39;re really doing is rejecting<br>
special values such as NaN on policy grounds.=C2=A0 I would ask first<br>
if that policy is sane at all.=C2=A0 (I&#39;d lean to &quot;not&quot; --- i=
f we allow<br>
it in the input JSON, why not in the output?)=C2=A0 If it is sane, the<br>
error message needs to be far more specific.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 regards, tom lane<br>
</blockquote></div><br clear=3D"all"><div><b>Consistent error message relat=
ed to type:</b><br><br>Agree that the number is not a PostgreSQL type and n=
eeds a change. As Tom suggested, we can say &quot;type numeric&quot; here. =
However, I have seen two variants of error messages here: (1) When the inpu=
t is numeric and (2) when the input is string. For first, we have error mes=
sages like:<br><font face=3D"monospace">numeric argument of jsonpath item m=
ethod .%s() is out of range for type double precision</font><br><br></div><=
div>and for the second, it is like:<br><font face=3D"monospace">string argu=
ment of jsonpath item method .%s() is not a valid representation of a doubl=
e precision number</font><br><br>The second form says &quot;double precisio=
n number&quot;. So, in the decimal/number case, should we use &quot;numeric=
 number&quot; and then similarly &quot;big integer number&quot;?<br><br>Wha=
t if we use phrases like &quot;for type double precision&quot; at both plac=
es, like:<br><font face=3D"monospace">numeric argument of jsonpath item met=
hod .%s() is out of range for type double precision<br>string argument of j=
sonpath item method .%s() is not a valid representation for type double pre=
cision</font><br><br>With this, the rest will be like:<br>for type numeric<=
br>for type bigint<br>for type integer<br><br>Suggestions?<br><br>---<br><b=
r><b>Showing input string in the error message:</b><br><br>argument &quot;.=
..input string here...&quot; of jsonpath item method .%s() is out of range =
for type numeric<br><br>If we add the input string in the error, then for s=
ome errors, it will be too big, for example:<br><br><font face=3D"monospace=
">-ERROR: =C2=A0numeric argument of jsonpath item method .double() is out o=
f range for type double precision<br>+ERROR: =C2=A0argument &quot;100000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
000000000000000000000000000000000000000000000000000000000000000000000000000=
00000000000000000&quot; of jsonpath item method .double() is out of range f=
or type double precision</font><br><br>Also, for non-string input, we need =
to convert numeric to string just for the error message, which seems overki=
ll.<br><br>On another note, irrespective of these changes, is it good to sh=
ow the given input in the error messages? Error messages are logged and may=
 leak some details.</div><div><br>I think the existing way seems ok.<br><br=
>---<br><br><b>NaN and Infinity restrictions:</b><br><br>I am not sure why =
NaN and Infinity are not allowed in conversion to double precision (.double=
() method). I have used the same restriction for .decimal() and .number(). =
However, as you said, we should have error messages more specific. I tried =
that in the attached patch; please have your views. I have the following wo=
rdings for that error message:<br><font face=3D"monospace">&quot;NaN or Inf=
inity is not allowed for jsonpath item method .%s()&quot;</font><br><br>Sug=
gestions...<br><br></div><div><br></div><div>Thanks</div><span class=3D"gma=
il_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signatur=
e"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div d=
ir=3D"ltr">Jeevan Chalke<br><i>Principal, Manager<br>Product Development</i=
><br><span></span><br><span></span><span></span><img height=3D"60" width=3D=
"180" src=3D"https://ci3.googleusercontent.com/mail-sig/AIorK4yTnojkzOao3Bh=
tEiPwoUi3phZHCVxIe3hMvKqC0iJJ77R_VaQc6coM4Vg6UkaVsAGqZrQR8gU"><span style=
=3D"font-size:11pt;font-family:Arial;color:rgb(255,62,0);background-color:r=
gb(255,255,255);font-weight:700;font-style:normal;font-variant:normal;text-=
decoration:none;vertical-align:baseline;white-space:pre-wrap"><br><br><a hr=
ef=3D"http://edbpostgres.com" target=3D"_blank">edbpostgres.com</a></span><=
/div></div></div></div></div></div></div></div></div>

--000000000000a0d1c20610256285--

--000000000000a0d1c40610256287
Content-Type: application/octet-stream;
	name="improve_error_for_Nan_Infinity.patch.no"
Content-Disposition: attachment;
	filename="improve_error_for_Nan_Infinity.patch.no"
Content-Transfer-Encoding: base64
Content-ID: <f_ls033gmy0>
X-Attachment-Id: f_ls033gmy0

Y29tbWl0IGMxY2E3NWFiZjBiNzdiOTM1OWI0NTc0NDFhZWZkMzk2OGQwYjVhNTgKQXV0aG9yOiBK
ZWV2YW4gQ2hhbGtlIDxqZWV2YW4uY2hhbGtlQGVudGVycHJpc2VkYi5jb20+CkRhdGU6ICAgVHVl
IEphbiAzMCAwOToyNDowMCAyMDI0ICswNTMwCgogICAgSW1wcm92ZSBlcnJvciBtZXNzYWdlIGZv
ciBOYU4gb3IgSW5maW5pdHkgaW5wdXRzIGZvciBqc29ucGF0aCBpdGVtLgogICAgCiAgICBKZWV2
YW4gQ2hhbGtlLCBwZXIgc3VnZ2VzdGlvbiBmcm9tIFRvbSBMYW5lLgoKZGlmZiAtLWdpdCBhL3Ny
Yy9iYWNrZW5kL3V0aWxzL2FkdC9qc29ucGF0aF9leGVjLmMgYi9zcmMvYmFja2VuZC91dGlscy9h
ZHQvanNvbnBhdGhfZXhlYy5jCmluZGV4IDIzZDM3NWQuLjA1NjdiMTcgMTAwNjQ0Ci0tLSBhL3Ny
Yy9iYWNrZW5kL3V0aWxzL2FkdC9qc29ucGF0aF9leGVjLmMKKysrIGIvc3JjL2JhY2tlbmQvdXRp
bHMvYWR0L2pzb25wYXRoX2V4ZWMuYwpAQCAtMTA0OSwxMSArMTA0OSwxNiBAQCBleGVjdXRlSXRl
bU9wdFVud3JhcFRhcmdldChKc29uUGF0aEV4ZWNDb250ZXh0ICpjeHQsIEpzb25QYXRoSXRlbSAq
anNwLAogCQkJCQkJCQkJCQl0bXAsCiAJCQkJCQkJCQkJCShOb2RlICopICZlc2NvbnRleHQpOwog
Ci0JCQkJCWlmIChlc2NvbnRleHQuZXJyb3Jfb2NjdXJyZWQgfHwgaXNpbmYodmFsKSB8fCBpc25h
bih2YWwpKQorCQkJCQlpZiAoZXNjb250ZXh0LmVycm9yX29jY3VycmVkKQogCQkJCQkJUkVUVVJO
X0VSUk9SKGVyZXBvcnQoRVJST1IsCiAJCQkJCQkJCQkJCSAoZXJyY29kZShFUlJDT0RFX05PTl9O
VU1FUklDX1NRTF9KU09OX0lURU0pLAogCQkJCQkJCQkJCQkgIGVycm1zZygibnVtZXJpYyBhcmd1
bWVudCBvZiBqc29ucGF0aCBpdGVtIG1ldGhvZCAuJXMoKSBpcyBvdXQgb2YgcmFuZ2UgZm9yIHR5
cGUgZG91YmxlIHByZWNpc2lvbiIsCiAJCQkJCQkJCQkJCQkJIGpzcE9wZXJhdGlvbk5hbWUoanNw
LT50eXBlKSkpKSk7CisJCQkJCWlmIChpc2luZih2YWwpIHx8IGlzbmFuKHZhbCkpCisJCQkJCQlS
RVRVUk5fRVJST1IoZXJlcG9ydChFUlJPUiwKKwkJCQkJCQkJCQkJIChlcnJjb2RlKEVSUkNPREVf
Tk9OX05VTUVSSUNfU1FMX0pTT05fSVRFTSksCisJCQkJCQkJCQkJCSAgZXJybXNnKCJOYU4gb3Ig
SW5maW5pdHkgaXMgbm90IGFsbG93ZWQgZm9yIGpzb25wYXRoIGl0ZW0gbWV0aG9kIC4lcygpIiwK
KwkJCQkJCQkJCQkJCQkganNwT3BlcmF0aW9uTmFtZShqc3AtPnR5cGUpKSkpKTsKIAkJCQkJcmVz
ID0ganBlck9rOwogCQkJCX0KIAkJCQllbHNlIGlmIChqYi0+dHlwZSA9PSBqYnZTdHJpbmcpCkBA
IC0xMDcwLDExICsxMDc1LDE2IEBAIGV4ZWN1dGVJdGVtT3B0VW53cmFwVGFyZ2V0KEpzb25QYXRo
RXhlY0NvbnRleHQgKmN4dCwgSnNvblBhdGhJdGVtICpqc3AsCiAJCQkJCQkJCQkJCXRtcCwKIAkJ
CQkJCQkJCQkJKE5vZGUgKikgJmVzY29udGV4dCk7CiAKLQkJCQkJaWYgKGVzY29udGV4dC5lcnJv
cl9vY2N1cnJlZCB8fCBpc2luZih2YWwpIHx8IGlzbmFuKHZhbCkpCisJCQkJCWlmIChlc2NvbnRl
eHQuZXJyb3Jfb2NjdXJyZWQpCiAJCQkJCQlSRVRVUk5fRVJST1IoZXJlcG9ydChFUlJPUiwKIAkJ
CQkJCQkJCQkJIChlcnJjb2RlKEVSUkNPREVfTk9OX05VTUVSSUNfU1FMX0pTT05fSVRFTSksCiAJ
CQkJCQkJCQkJCSAgZXJybXNnKCJzdHJpbmcgYXJndW1lbnQgb2YganNvbnBhdGggaXRlbSBtZXRo
b2QgLiVzKCkgaXMgbm90IGEgdmFsaWQgcmVwcmVzZW50YXRpb24gb2YgYSBkb3VibGUgcHJlY2lz
aW9uIG51bWJlciIsCiAJCQkJCQkJCQkJCQkJIGpzcE9wZXJhdGlvbk5hbWUoanNwLT50eXBlKSkp
KSk7CisJCQkJCWlmIChpc2luZih2YWwpIHx8IGlzbmFuKHZhbCkpCisJCQkJCQlSRVRVUk5fRVJS
T1IoZXJlcG9ydChFUlJPUiwKKwkJCQkJCQkJCQkJIChlcnJjb2RlKEVSUkNPREVfTk9OX05VTUVS
SUNfU1FMX0pTT05fSVRFTSksCisJCQkJCQkJCQkJCSAgZXJybXNnKCJOYU4gb3IgSW5maW5pdHkg
aXMgbm90IGFsbG93ZWQgZm9yIGpzb25wYXRoIGl0ZW0gbWV0aG9kIC4lcygpIiwKKwkJCQkJCQkJ
CQkJCQkganNwT3BlcmF0aW9uTmFtZShqc3AtPnR5cGUpKSkpKTsKIAogCQkJCQlqYiA9ICZqYnY7
CiAJCQkJCWpiLT50eXBlID0gamJ2TnVtZXJpYzsKQEAgLTEyODcsNyArMTI5Nyw3IEBAIGV4ZWN1
dGVJdGVtT3B0VW53cmFwVGFyZ2V0KEpzb25QYXRoRXhlY0NvbnRleHQgKmN4dCwgSnNvblBhdGhJ
dGVtICpqc3AsCiAJCQkJCWlmIChudW1lcmljX2lzX25hbihudW0pIHx8IG51bWVyaWNfaXNfaW5m
KG51bSkpCiAJCQkJCQlSRVRVUk5fRVJST1IoZXJlcG9ydChFUlJPUiwKIAkJCQkJCQkJCQkJIChl
cnJjb2RlKEVSUkNPREVfTk9OX05VTUVSSUNfU1FMX0pTT05fSVRFTSksCi0JCQkJCQkJCQkJCSAg
ZXJybXNnKCJudW1lcmljIGFyZ3VtZW50IG9mIGpzb25wYXRoIGl0ZW0gbWV0aG9kIC4lcygpIGlz
IG91dCBvZiByYW5nZSBmb3IgdHlwZSBkZWNpbWFsIG9yIG51bWJlciIsCisJCQkJCQkJCQkJCSAg
ZXJybXNnKCJOYU4gb3IgSW5maW5pdHkgaXMgbm90IGFsbG93ZWQgZm9yIGpzb25wYXRoIGl0ZW0g
bWV0aG9kIC4lcygpIiwKIAkJCQkJCQkJCQkJCQkganNwT3BlcmF0aW9uTmFtZShqc3AtPnR5cGUp
KSkpKTsKIAogCQkJCQlpZiAoanNwLT50eXBlID09IGpwaURlY2ltYWwpCkBAIC0xMzE5LDcgKzEz
MjksNyBAQCBleGVjdXRlSXRlbU9wdFVud3JhcFRhcmdldChKc29uUGF0aEV4ZWNDb250ZXh0ICpj
eHQsIEpzb25QYXRoSXRlbSAqanNwLAogCQkJCQlpZiAobnVtZXJpY19pc19uYW4obnVtKSB8fCBu
dW1lcmljX2lzX2luZihudW0pKQogCQkJCQkJUkVUVVJOX0VSUk9SKGVyZXBvcnQoRVJST1IsCiAJ
CQkJCQkJCQkJCSAoZXJyY29kZShFUlJDT0RFX05PTl9OVU1FUklDX1NRTF9KU09OX0lURU0pLAot
CQkJCQkJCQkJCQkgIGVycm1zZygic3RyaW5nIGFyZ3VtZW50IG9mIGpzb25wYXRoIGl0ZW0gbWV0
aG9kIC4lcygpIGlzIG5vdCBhIHZhbGlkIHJlcHJlc2VudGF0aW9uIG9mIGEgZGVjaW1hbCBvciBu
dW1iZXIiLAorCQkJCQkJCQkJCQkgIGVycm1zZygiTmFOIG9yIEluZmluaXR5IGlzIG5vdCBhbGxv
d2VkIGZvciBqc29ucGF0aCBpdGVtIG1ldGhvZCAuJXMoKSIsCiAJCQkJCQkJCQkJCQkJIGpzcE9w
ZXJhdGlvbk5hbWUoanNwLT50eXBlKSkpKSk7CiAKIAkJCQkJcmVzID0ganBlck9rOwpkaWZmIC0t
Z2l0IGEvc3JjL3Rlc3QvcmVncmVzcy9leHBlY3RlZC9qc29uYl9qc29ucGF0aC5vdXQgYi9zcmMv
dGVzdC9yZWdyZXNzL2V4cGVjdGVkL2pzb25iX2pzb25wYXRoLm91dAppbmRleCBlZWEyYWYzLi45
NTQwOGFkIDEwMDY0NAotLS0gYS9zcmMvdGVzdC9yZWdyZXNzL2V4cGVjdGVkL2pzb25iX2pzb25w
YXRoLm91dAorKysgYi9zcmMvdGVzdC9yZWdyZXNzL2V4cGVjdGVkL2pzb25iX2pzb25wYXRoLm91
dApAQCAtMTUwMCwxMyArMTUwMCwxMyBAQCBFUlJPUjogIHN0cmluZyBhcmd1bWVudCBvZiBqc29u
cGF0aCBpdGVtIG1ldGhvZCAuZG91YmxlKCkgaXMgbm90IGEgdmFsaWQgcmVwcmVzZQogc2VsZWN0
IGpzb25iX3BhdGhfcXVlcnkoJzFlMTAwMCcsICckLmRvdWJsZSgpJyk7CiBFUlJPUjogIG51bWVy
aWMgYXJndW1lbnQgb2YganNvbnBhdGggaXRlbSBtZXRob2QgLmRvdWJsZSgpIGlzIG91dCBvZiBy
YW5nZSBmb3IgdHlwZSBkb3VibGUgcHJlY2lzaW9uCiBzZWxlY3QganNvbmJfcGF0aF9xdWVyeSgn
Im5hbiInLCAnJC5kb3VibGUoKScpOwotRVJST1I6ICBzdHJpbmcgYXJndW1lbnQgb2YganNvbnBh
dGggaXRlbSBtZXRob2QgLmRvdWJsZSgpIGlzIG5vdCBhIHZhbGlkIHJlcHJlc2VudGF0aW9uIG9m
IGEgZG91YmxlIHByZWNpc2lvbiBudW1iZXIKK0VSUk9SOiAgTmFOIG9yIEluZmluaXR5IGlzIG5v
dCBhbGxvd2VkIGZvciBqc29ucGF0aCBpdGVtIG1ldGhvZCAuZG91YmxlKCkKIHNlbGVjdCBqc29u
Yl9wYXRoX3F1ZXJ5KCciTmFOIicsICckLmRvdWJsZSgpJyk7Ci1FUlJPUjogIHN0cmluZyBhcmd1
bWVudCBvZiBqc29ucGF0aCBpdGVtIG1ldGhvZCAuZG91YmxlKCkgaXMgbm90IGEgdmFsaWQgcmVw
cmVzZW50YXRpb24gb2YgYSBkb3VibGUgcHJlY2lzaW9uIG51bWJlcgorRVJST1I6ICBOYU4gb3Ig
SW5maW5pdHkgaXMgbm90IGFsbG93ZWQgZm9yIGpzb25wYXRoIGl0ZW0gbWV0aG9kIC5kb3VibGUo
KQogc2VsZWN0IGpzb25iX3BhdGhfcXVlcnkoJyJpbmYiJywgJyQuZG91YmxlKCknKTsKLUVSUk9S
OiAgc3RyaW5nIGFyZ3VtZW50IG9mIGpzb25wYXRoIGl0ZW0gbWV0aG9kIC5kb3VibGUoKSBpcyBu
b3QgYSB2YWxpZCByZXByZXNlbnRhdGlvbiBvZiBhIGRvdWJsZSBwcmVjaXNpb24gbnVtYmVyCitF
UlJPUjogIE5hTiBvciBJbmZpbml0eSBpcyBub3QgYWxsb3dlZCBmb3IganNvbnBhdGggaXRlbSBt
ZXRob2QgLmRvdWJsZSgpCiBzZWxlY3QganNvbmJfcGF0aF9xdWVyeSgnIi1pbmYiJywgJyQuZG91
YmxlKCknKTsKLUVSUk9SOiAgc3RyaW5nIGFyZ3VtZW50IG9mIGpzb25wYXRoIGl0ZW0gbWV0aG9k
IC5kb3VibGUoKSBpcyBub3QgYSB2YWxpZCByZXByZXNlbnRhdGlvbiBvZiBhIGRvdWJsZSBwcmVj
aXNpb24gbnVtYmVyCitFUlJPUjogIE5hTiBvciBJbmZpbml0eSBpcyBub3QgYWxsb3dlZCBmb3Ig
anNvbnBhdGggaXRlbSBtZXRob2QgLmRvdWJsZSgpCiBzZWxlY3QganNvbmJfcGF0aF9xdWVyeSgn
ImluZiInLCAnJC5kb3VibGUoKScsIHNpbGVudCA9PiB0cnVlKTsKICBqc29uYl9wYXRoX3F1ZXJ5
IAogLS0tLS0tLS0tLS0tLS0tLS0tCkBAIC0yMTUyLDEzICsyMTUyLDEzIEBAIHNlbGVjdCBqc29u
Yl9wYXRoX3F1ZXJ5KCcxZTEwMDAnLCAnJC5kZWNpbWFsKCknKTsKICgxIHJvdykKIAogc2VsZWN0
IGpzb25iX3BhdGhfcXVlcnkoJyJuYW4iJywgJyQuZGVjaW1hbCgpJyk7Ci1FUlJPUjogIHN0cmlu
ZyBhcmd1bWVudCBvZiBqc29ucGF0aCBpdGVtIG1ldGhvZCAuZGVjaW1hbCgpIGlzIG5vdCBhIHZh
bGlkIHJlcHJlc2VudGF0aW9uIG9mIGEgZGVjaW1hbCBvciBudW1iZXIKK0VSUk9SOiAgTmFOIG9y
IEluZmluaXR5IGlzIG5vdCBhbGxvd2VkIGZvciBqc29ucGF0aCBpdGVtIG1ldGhvZCAuZGVjaW1h
bCgpCiBzZWxlY3QganNvbmJfcGF0aF9xdWVyeSgnIk5hTiInLCAnJC5kZWNpbWFsKCknKTsKLUVS
Uk9SOiAgc3RyaW5nIGFyZ3VtZW50IG9mIGpzb25wYXRoIGl0ZW0gbWV0aG9kIC5kZWNpbWFsKCkg
aXMgbm90IGEgdmFsaWQgcmVwcmVzZW50YXRpb24gb2YgYSBkZWNpbWFsIG9yIG51bWJlcgorRVJS
T1I6ICBOYU4gb3IgSW5maW5pdHkgaXMgbm90IGFsbG93ZWQgZm9yIGpzb25wYXRoIGl0ZW0gbWV0
aG9kIC5kZWNpbWFsKCkKIHNlbGVjdCBqc29uYl9wYXRoX3F1ZXJ5KCciaW5mIicsICckLmRlY2lt
YWwoKScpOwotRVJST1I6ICBzdHJpbmcgYXJndW1lbnQgb2YganNvbnBhdGggaXRlbSBtZXRob2Qg
LmRlY2ltYWwoKSBpcyBub3QgYSB2YWxpZCByZXByZXNlbnRhdGlvbiBvZiBhIGRlY2ltYWwgb3Ig
bnVtYmVyCitFUlJPUjogIE5hTiBvciBJbmZpbml0eSBpcyBub3QgYWxsb3dlZCBmb3IganNvbnBh
dGggaXRlbSBtZXRob2QgLmRlY2ltYWwoKQogc2VsZWN0IGpzb25iX3BhdGhfcXVlcnkoJyItaW5m
IicsICckLmRlY2ltYWwoKScpOwotRVJST1I6ICBzdHJpbmcgYXJndW1lbnQgb2YganNvbnBhdGgg
aXRlbSBtZXRob2QgLmRlY2ltYWwoKSBpcyBub3QgYSB2YWxpZCByZXByZXNlbnRhdGlvbiBvZiBh
IGRlY2ltYWwgb3IgbnVtYmVyCitFUlJPUjogIE5hTiBvciBJbmZpbml0eSBpcyBub3QgYWxsb3dl
ZCBmb3IganNvbnBhdGggaXRlbSBtZXRob2QgLmRlY2ltYWwoKQogc2VsZWN0IGpzb25iX3BhdGhf
cXVlcnkoJyJpbmYiJywgJyQuZGVjaW1hbCgpJywgc2lsZW50ID0+IHRydWUpOwogIGpzb25iX3Bh
dGhfcXVlcnkgCiAtLS0tLS0tLS0tLS0tLS0tLS0KQEAgLTI0NDgsMTMgKzI0NDgsMTMgQEAgc2Vs
ZWN0IGpzb25iX3BhdGhfcXVlcnkoJzFlMTAwMCcsICckLm51bWJlcigpJyk7CiAoMSByb3cpCiAK
IHNlbGVjdCBqc29uYl9wYXRoX3F1ZXJ5KCcibmFuIicsICckLm51bWJlcigpJyk7Ci1FUlJPUjog
IHN0cmluZyBhcmd1bWVudCBvZiBqc29ucGF0aCBpdGVtIG1ldGhvZCAubnVtYmVyKCkgaXMgbm90
IGEgdmFsaWQgcmVwcmVzZW50YXRpb24gb2YgYSBkZWNpbWFsIG9yIG51bWJlcgorRVJST1I6ICBO
YU4gb3IgSW5maW5pdHkgaXMgbm90IGFsbG93ZWQgZm9yIGpzb25wYXRoIGl0ZW0gbWV0aG9kIC5u
dW1iZXIoKQogc2VsZWN0IGpzb25iX3BhdGhfcXVlcnkoJyJOYU4iJywgJyQubnVtYmVyKCknKTsK
LUVSUk9SOiAgc3RyaW5nIGFyZ3VtZW50IG9mIGpzb25wYXRoIGl0ZW0gbWV0aG9kIC5udW1iZXIo
KSBpcyBub3QgYSB2YWxpZCByZXByZXNlbnRhdGlvbiBvZiBhIGRlY2ltYWwgb3IgbnVtYmVyCitF
UlJPUjogIE5hTiBvciBJbmZpbml0eSBpcyBub3QgYWxsb3dlZCBmb3IganNvbnBhdGggaXRlbSBt
ZXRob2QgLm51bWJlcigpCiBzZWxlY3QganNvbmJfcGF0aF9xdWVyeSgnImluZiInLCAnJC5udW1i
ZXIoKScpOwotRVJST1I6ICBzdHJpbmcgYXJndW1lbnQgb2YganNvbnBhdGggaXRlbSBtZXRob2Qg
Lm51bWJlcigpIGlzIG5vdCBhIHZhbGlkIHJlcHJlc2VudGF0aW9uIG9mIGEgZGVjaW1hbCBvciBu
dW1iZXIKK0VSUk9SOiAgTmFOIG9yIEluZmluaXR5IGlzIG5vdCBhbGxvd2VkIGZvciBqc29ucGF0
aCBpdGVtIG1ldGhvZCAubnVtYmVyKCkKIHNlbGVjdCBqc29uYl9wYXRoX3F1ZXJ5KCciLWluZiIn
LCAnJC5udW1iZXIoKScpOwotRVJST1I6ICBzdHJpbmcgYXJndW1lbnQgb2YganNvbnBhdGggaXRl
bSBtZXRob2QgLm51bWJlcigpIGlzIG5vdCBhIHZhbGlkIHJlcHJlc2VudGF0aW9uIG9mIGEgZGVj
aW1hbCBvciBudW1iZXIKK0VSUk9SOiAgTmFOIG9yIEluZmluaXR5IGlzIG5vdCBhbGxvd2VkIGZv
ciBqc29ucGF0aCBpdGVtIG1ldGhvZCAubnVtYmVyKCkKIHNlbGVjdCBqc29uYl9wYXRoX3F1ZXJ5
KCciaW5mIicsICckLm51bWJlcigpJywgc2lsZW50ID0+IHRydWUpOwogIGpzb25iX3BhdGhfcXVl
cnkgCiAtLS0tLS0tLS0tLS0tLS0tLS0K
--000000000000a0d1c40610256287--