Content-Type: multipart/mixed; boundary="------------7nN01B80S1J3FmnI0iSpBOey"
Message-ID: <91a1b0ab-2c6c-4471-b7a4-ee8ee8aed64e@gmail.com>
Date: Sat, 5 Sep 2026 11:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Internal error codes triggered by regression tests and user
 queries, take 2
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 Justin Pryzby <pryzby@telsasoft.com>
References: <94ac928b-8370-4db5-ada5-579a9ebc089d@gmail.com>
 <697477.1787754418@sss.pgh.pa.us>
 <mosliefjrclrikqpsasjy5ibzowba6vwk4ygimouikiht2i5pb@5g562jqflxsz>
 <73eb724a-c1a3-456c-be12-0375d4556b67@gmail.com>
 <apUcBVyazHEW5pcg@paquier.xyz>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <apUcBVyazHEW5pcg@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/91a1b0ab-2c6c-4471-b7a4-ee8ee8aed64e%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------7nN01B80S1J3FmnI0iSpBOey
Content-Type: multipart/alternative;
 boundary="------------ZLSn1Jqz9XOVusTFEU8MY0zP"

--------------ZLSn1Jqz9XOVusTFEU8MY0zP
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Michael,

31.08.2026 09:15, Michael Paquier wrote:
> Not all of them are.  See below for details.

Thank you for having a look! Please find v2 patch with 7 approved changes
attached.

> Looking (finally) at the list you have sent in your patch, I can get
> on board for:
> - getObjectDescription(), can be queried with a function officially
> documented.
I kept the message as-is, as it's used in 3 other places, with elog(ERROR), but still...
> - ATPrepAddPrimaryKey().  This one is a bug to me, reachable with SQL.
already translatable
> - transformColumnDefinition().  Also a bug to me.
already translatable, thanks to AddRelationNotNullConstraints(), I
borrowed ERRCODE_SYNTAX_ERROR from it
> - pg_get_shmem_allocations_numa.  Bug.
a unique message, looks good enough to be user-visible
> - acldefault() is documented.  Seems worth fixing for correctness,
> documented function.
the message "unrecognized object type abbreviation: %c" is unique, a
closest one is "unrecognized object type \"%s\"", but I don't find it
suitable here
> - AdjustIntervalForTypmod().  Documented feature.
the message is unique, looks good too
> - The pl_gram.y one looks like a defect to me by not assigning an
> error code.
reused the closest translatable message "unrecognized %s option \"%s\""

> But not for these:
> - relation_open(), incorrect internal state from the caller.
> - try_relation_open(), incorrect internal state from the caller.
> coerce_type(), also an internal state.  unknownin() is also an
> - "internal" input, non-documented SQL function.
> - check_float8_array().  Your case involves float8_regr_intercept(),
> which is a final aggregate function.  It is not documented, and should
> never really be called directly.
> - get_range_io_data().  Cannot get excited about this one, either, as
> your case involves the direct call of an input function.  Can this
> happen with more patterns?
> - test_pglz_decompress() is test code, no need to worry about it.

I agree, let's leave them aside until other (documented) ways to reach
them found.

>> The other one is the unclear definition of internal/XX000 errors in
>> principle. As far as I can see, it varies from "all the errors that have
>> no specific code assigned" to "critical errors, similar to failed asserts"
>> (and probably a substitute for asserts in production). And as Andres (and
>> I too) find it useful to search for XX000 in production logs, it means
>> they are interpreted per the second definition. In this case, it makes
>> sense to define missing codes for cases which are not worth paying
>> attention to in production, e.g. "#print_strict_params XXX". Moreover, if
>> the second definition (XX000 error ~ failed assert) is going to be
>> accepted, it seems sensible to have no such errors produced during
>> regression tests (like no assertion failures).
> I think that I would draw a line depending on the documentation.  If
> a function is documented as usable, or callable through a view, it
> sounds fair to me to assume that a user gets an error code that fits
> with the incorrect behavior provided as input argument.  Input
> function for types, test code, direct function calls to embedded
> facilities like aggregates, or anything like that, not documented, is
> not worth bothering.  The fact that none of them is documented is an
> argument good enough for me to state that we don't really expect users
> to use these this way.
>
> The important piece to keep in mind is that non-internal ereport()
> calls mean translation.  There is no point in providing translation
> for states that we expect users to never see in the field, and the
> docs define what we make user-visible.

Thank you for sharing your point of view! I'll review my collection in
light of it.

Best regards,
Alexander
--------------ZLSn1Jqz9XOVusTFEU8MY0zP
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello Michael,<br>
      <br>
      31.08.2026 09:15, Michael Paquier wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:apUcBVyazHEW5pcg@paquier.xyz">
      <pre wrap="" class="moz-quote-pre">Not all of them are.  See below for details.
</pre>
    </blockquote>
    <br>
    Thank you for having a look! Please find v2 patch with 7 approved
    changes<br>
    attached.<br>
    <br>
    <blockquote type="cite" cite="mid:apUcBVyazHEW5pcg@paquier.xyz">
      <pre wrap="" class="moz-quote-pre">Looking (finally) at the list you have sent in your patch, I can get
on board for:
- getObjectDescription(), can be queried with a function officially
documented.</pre>
    </blockquote>
    I kept the message as-is, as it's used in 3 other places, with
    elog(ERROR), but still...<br>
    <blockquote type="cite" cite="mid:apUcBVyazHEW5pcg@paquier.xyz">
      <pre wrap="" class="moz-quote-pre">- ATPrepAddPrimaryKey().  This one is a bug to me, reachable with SQL.</pre>
    </blockquote>
    already translatable<br>
    <blockquote type="cite" cite="mid:apUcBVyazHEW5pcg@paquier.xyz">
      <pre wrap="" class="moz-quote-pre">- transformColumnDefinition().  Also a bug to me.</pre>
    </blockquote>
    already translatable, thanks to AddRelationNotNullConstraints(), I<br>
    borrowed ERRCODE_SYNTAX_ERROR from it<br>
    <blockquote type="cite" cite="mid:apUcBVyazHEW5pcg@paquier.xyz">
      <pre wrap="" class="moz-quote-pre">- pg_get_shmem_allocations_numa.  Bug.</pre>
    </blockquote>
    a unique message, looks good enough to be user-visible<br>
    <blockquote type="cite" cite="mid:apUcBVyazHEW5pcg@paquier.xyz">
      <pre wrap="" class="moz-quote-pre">- acldefault() is documented.  Seems worth fixing for correctness,
documented function.</pre>
    </blockquote>
    the message "unrecognized object type abbreviation: %c" is unique, a<br>
    closest one is "unrecognized object type \"%s\"", but I don't find
    it<br>
    suitable here<br>
    <blockquote type="cite" cite="mid:apUcBVyazHEW5pcg@paquier.xyz">
      <pre wrap="" class="moz-quote-pre">- AdjustIntervalForTypmod().  Documented feature.</pre>
    </blockquote>
    the message is unique, looks good too<br>
    <blockquote type="cite" cite="mid:apUcBVyazHEW5pcg@paquier.xyz">
      <pre wrap="" class="moz-quote-pre">- The pl_gram.y one looks like a defect to me by not assigning an
error code.</pre>
    </blockquote>
    reused the closest translatable message "unrecognized %s option
    \"%s\""<br>
    <br>
    <blockquote type="cite" cite="mid:apUcBVyazHEW5pcg@paquier.xyz">
      <pre wrap="" class="moz-quote-pre">But not for these:
- relation_open(), incorrect internal state from the caller.
- try_relation_open(), incorrect internal state from the caller.
coerce_type(), also an internal state.  unknownin() is also an
- "internal" input, non-documented SQL function.
- check_float8_array().  Your case involves float8_regr_intercept(),
which is a final aggregate function.  It is not documented, and should
never really be called directly.
- get_range_io_data().  Cannot get excited about this one, either, as
your case involves the direct call of an input function.  Can this
happen with more patterns?
- test_pglz_decompress() is test code, no need to worry about it.</pre>
    </blockquote>
    <br>
    I agree, let's leave them aside until other (documented) ways to
    reach<br>
    them found.<br>
    <br>
    <blockquote type="cite" cite="mid:apUcBVyazHEW5pcg@paquier.xyz">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">The other one is the unclear definition of internal/XX000 errors in
principle. As far as I can see, it varies from "all the errors that have
no specific code assigned" to "critical errors, similar to failed asserts"
(and probably a substitute for asserts in production). And as Andres (and
I too) find it useful to search for XX000 in production logs, it means
they are interpreted per the second definition. In this case, it makes
sense to define missing codes for cases which are not worth paying
attention to in production, e.g. "#print_strict_params XXX". Moreover, if
the second definition (XX000 error ~ failed assert) is going to be
accepted, it seems sensible to have no such errors produced during
regression tests (like no assertion failures).
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
I think that I would draw a line depending on the documentation.  If
a function is documented as usable, or callable through a view, it
sounds fair to me to assume that a user gets an error code that fits
with the incorrect behavior provided as input argument.  Input
function for types, test code, direct function calls to embedded
facilities like aggregates, or anything like that, not documented, is
not worth bothering.  The fact that none of them is documented is an
argument good enough for me to state that we don't really expect users
to use these this way.

The important piece to keep in mind is that non-internal ereport()
calls mean translation.  There is no point in providing translation
for states that we expect users to never see in the field, and the
docs define what we make user-visible.
</pre>
    </blockquote>
    <br>
    Thank you for sharing your point of view! I'll review my collection
    in<br>
    light of it.<br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------ZLSn1Jqz9XOVusTFEU8MY0zP--

--------------7nN01B80S1J3FmnI0iSpBOey
Content-Type: text/x-patch; charset=UTF-8;
 name="v2-Define-missing-errcodes.patch"
Content-Disposition: attachment; filename="v2-Define-missing-errcodes.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2NhdGFsb2cvb2JqZWN0YWRkcmVzcy5jIGIvc3Jj
L2JhY2tlbmQvY2F0YWxvZy9vYmplY3RhZGRyZXNzLmMKaW5kZXggNzAzNzU0YTgxMjMuLmNm
NmY0ZDg2NmU0IDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC9jYXRhbG9nL29iamVjdGFkZHJl
c3MuYworKysgYi9zcmMvYmFja2VuZC9jYXRhbG9nL29iamVjdGFkZHJlc3MuYwpAQCAtNDMx
NCw3ICs0MzE0LDkgQEAgZ2V0T2JqZWN0RGVzY3JpcHRpb24oY29uc3QgT2JqZWN0QWRkcmVz
cyAqb2JqZWN0LCBib29sIG1pc3Npbmdfb2spCiAJCQl9CiAKIAkJZGVmYXVsdDoKLQkJCWVs
b2coRVJST1IsICJ1bnN1cHBvcnRlZCBvYmplY3QgY2xhc3M6ICV1Iiwgb2JqZWN0LT5jbGFz
c0lkKTsKKwkJCWVyZXBvcnQoRVJST1IsCisJCQkJCShlcnJjb2RlKEVSUkNPREVfV1JPTkdf
T0JKRUNUX1RZUEUpLAorCQkJCQkgZXJybXNnKCJ1bnN1cHBvcnRlZCBvYmplY3QgY2xhc3M6
ICV1Iiwgb2JqZWN0LT5jbGFzc0lkKSkpOwogCX0KIAogCS8qIGFuIGVtcHR5IGJ1ZmZlciBp
cyBlcXVpdmFsZW50IHRvIG5vIG9iamVjdCBmb3VuZCAqLwpkaWZmIC0tZ2l0IGEvc3JjL2Jh
Y2tlbmQvY29tbWFuZHMvdGFibGVjbWRzLmMgYi9zcmMvYmFja2VuZC9jb21tYW5kcy90YWJs
ZWNtZHMuYwppbmRleCBmZDE0NGQ3ODNkOS4uYTM4NjVjMDJlMjAgMTAwNjQ0Ci0tLSBhL3Ny
Yy9iYWNrZW5kL2NvbW1hbmRzL3RhYmxlY21kcy5jCisrKyBiL3NyYy9iYWNrZW5kL2NvbW1h
bmRzL3RhYmxlY21kcy5jCkBAIC05NjMxLDYgKzk2MzEsNyBAQCBBVFByZXBBZGRQcmltYXJ5
S2V5KExpc3QgKip3cXVldWUsIFJlbGF0aW9uIHJlbCwgQWx0ZXJUYWJsZUNtZCAqY21kLAog
CQkJCXR1cCA9IGZpbmROb3ROdWxsQ29uc3RyYWludChjaGlsZHJlbGlkLCBzdHJWYWwoY29s
dW1uKSk7CiAJCQkJaWYgKCF0dXApCiAJCQkJCWVyZXBvcnQoRVJST1IsCisJCQkJCQkJZXJy
Y29kZShFUlJDT0RFX0lOVkFMSURfVEFCTEVfREVGSU5JVElPTiksCiAJCQkJCQkJZXJybXNn
KCJjb2x1bW4gXCIlc1wiIG9mIHRhYmxlIFwiJXNcIiBpcyBub3QgbWFya2VkIE5PVCBOVUxM
IiwKIAkJCQkJCQkJICAgc3RyVmFsKGNvbHVtbiksIGdldF9yZWxfbmFtZShjaGlsZHJlbGlk
KSkpOwogCQkJCS8qIHZlcmlmeSBpdCdzIGdvb2QgZW5vdWdoICovCmRpZmYgLS1naXQgYS9z
cmMvYmFja2VuZC9wYXJzZXIvcGFyc2VfdXRpbGNtZC5jIGIvc3JjL2JhY2tlbmQvcGFyc2Vy
L3BhcnNlX3V0aWxjbWQuYwppbmRleCBkODM2MTZhODUwNy4uMzYwYmNiYjJjYmQgMTAwNjQ0
Ci0tLSBhL3NyYy9iYWNrZW5kL3BhcnNlci9wYXJzZV91dGlsY21kLmMKKysrIGIvc3JjL2Jh
Y2tlbmQvcGFyc2VyL3BhcnNlX3V0aWxjbWQuYwpAQCAtNzk0LDggKzc5NCwxMCBAQCB0cmFu
c2Zvcm1Db2x1bW5EZWZpbml0aW9uKENyZWF0ZVN0bXRDb250ZXh0ICpjeHQsIENvbHVtbkRl
ZiAqY29sdW1uKQogCQkJCQlpZiAoY29uc3RyYWludC0+Y29ubmFtZSAmJgogCQkJCQkJbm90
bnVsbF9jb25zdHJhaW50LT5jb25uYW1lICYmCiAJCQkJCQlzdHJjbXAobm90bnVsbF9jb25z
dHJhaW50LT5jb25uYW1lLCBjb25zdHJhaW50LT5jb25uYW1lKSAhPSAwKQotCQkJCQkJZWxv
ZyhFUlJPUiwgImNvbmZsaWN0aW5nIG5vdC1udWxsIGNvbnN0cmFpbnQgbmFtZXMgXCIlc1wi
IGFuZCBcIiVzXCIiLAotCQkJCQkJCSBub3RudWxsX2NvbnN0cmFpbnQtPmNvbm5hbWUsIGNv
bnN0cmFpbnQtPmNvbm5hbWUpOworCQkJCQkJZXJlcG9ydChFUlJPUiwKKwkJCQkJCQkJZXJy
Y29kZShFUlJDT0RFX1NZTlRBWF9FUlJPUiksCisJCQkJCQkJCWVycm1zZygiY29uZmxpY3Rp
bmcgbm90LW51bGwgY29uc3RyYWludCBuYW1lcyBcIiVzXCIgYW5kIFwiJXNcIiIsCisJCQkJ
CQkJCQkgICBub3RudWxsX2NvbnN0cmFpbnQtPmNvbm5hbWUsIGNvbnN0cmFpbnQtPmNvbm5h
bWUpKTsKIAogCQkJCQlpZiAobm90bnVsbF9jb25zdHJhaW50LT5pc19ub19pbmhlcml0ICE9
IGNvbnN0cmFpbnQtPmlzX25vX2luaGVyaXQpCiAJCQkJCQllcmVwb3J0KEVSUk9SLApkaWZm
IC0tZ2l0IGEvc3JjL2JhY2tlbmQvc3RvcmFnZS9pcGMvc2htZW0uYyBiL3NyYy9iYWNrZW5k
L3N0b3JhZ2UvaXBjL3NobWVtLmMKaW5kZXggZjk3MWVlMjQxOTIuLmY3OGMzNGRhZWUxIDEw
MDY0NAotLS0gYS9zcmMvYmFja2VuZC9zdG9yYWdlL2lwYy9zaG1lbS5jCisrKyBiL3NyYy9i
YWNrZW5kL3N0b3JhZ2UvaXBjL3NobWVtLmMKQEAgLTEyMTAsNyArMTIxMCw5IEBAIHBnX2dl
dF9zaG1lbV9hbGxvY2F0aW9uc19udW1hKFBHX0ZVTkNUSU9OX0FSR1MpCiAJU2l6ZQkgICAq
bm9kZXM7CiAKIAlpZiAocGdfbnVtYV9pbml0KCkgPT0gLTEpCi0JCWVsb2coRVJST1IsICJs
aWJudW1hIGluaXRpYWxpemF0aW9uIGZhaWxlZCBvciBOVU1BIGlzIG5vdCBzdXBwb3J0ZWQg
b24gdGhpcyBwbGF0Zm9ybSIpOworCQllcmVwb3J0KEVSUk9SLAorCQkJCShlcnJjb2RlKEVS
UkNPREVfRkVBVFVSRV9OT1RfU1VQUE9SVEVEKSwKKwkJCQkgZXJybXNnKCJsaWJudW1hIGlu
aXRpYWxpemF0aW9uIGZhaWxlZCBvciBOVU1BIGlzIG5vdCBzdXBwb3J0ZWQgb24gdGhpcyBw
bGF0Zm9ybSIpKSk7CiAKIAlJbml0TWF0ZXJpYWxpemVkU1JGKGZjaW5mbywgMCk7CiAKZGlm
ZiAtLWdpdCBhL3NyYy9iYWNrZW5kL3V0aWxzL2FkdC9hY2wuYyBiL3NyYy9iYWNrZW5kL3V0
aWxzL2FkdC9hY2wuYwppbmRleCAyNWNkNWQwMjk2Yi4uMjM4NWMxZWJiZTkgMTAwNjQ0Ci0t
LSBhL3NyYy9iYWNrZW5kL3V0aWxzL2FkdC9hY2wuYworKysgYi9zcmMvYmFja2VuZC91dGls
cy9hZHQvYWNsLmMKQEAgLTk5Niw3ICs5OTYsOSBAQCBhY2xkZWZhdWx0X3NxbChQR19GVU5D
VElPTl9BUkdTKQogCQkJb2JqdHlwZSA9IE9CSkVDVF9UWVBFOwogCQkJYnJlYWs7CiAJCWRl
ZmF1bHQ6Ci0JCQllbG9nKEVSUk9SLCAidW5yZWNvZ25pemVkIG9iamVjdCB0eXBlIGFiYnJl
dmlhdGlvbjogJWMiLCBvYmp0eXBlYyk7CisJCQllcmVwb3J0KEVSUk9SLAorCQkJCQkoZXJy
Y29kZShFUlJDT0RFX1dST05HX09CSkVDVF9UWVBFKSwKKwkJCQkJIGVycm1zZygidW5yZWNv
Z25pemVkIG9iamVjdCB0eXBlIGFiYnJldmlhdGlvbjogJWMiLCBvYmp0eXBlYykpKTsKIAl9
CiAKIAlQR19SRVRVUk5fQUNMX1AoYWNsZGVmYXVsdChvYmp0eXBlLCBvd25lcikpOwpkaWZm
IC0tZ2l0IGEvc3JjL2JhY2tlbmQvdXRpbHMvYWR0L3RpbWVzdGFtcC5jIGIvc3JjL2JhY2tl
bmQvdXRpbHMvYWR0L3RpbWVzdGFtcC5jCmluZGV4IDljMTdiYTJmOTA1Li5hYjg2YTAzMjgw
ZSAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvdXRpbHMvYWR0L3RpbWVzdGFtcC5jCisrKyBi
L3NyYy9iYWNrZW5kL3V0aWxzL2FkdC90aW1lc3RhbXAuYwpAQCAtMTQ4OSw3ICsxNDg5LDkg
QEAgQWRqdXN0SW50ZXJ2YWxGb3JUeXBtb2QoSW50ZXJ2YWwgKmludGVydmFsLCBpbnQzMiB0
eXBtb2QsCiAJCQkvKiBmcmFjdGlvbmFsLXNlY29uZCByb3VuZGluZyB3aWxsIGJlIGRlYWx0
IHdpdGggYmVsb3cgKi8KIAkJfQogCQllbHNlCi0JCQllbG9nKEVSUk9SLCAidW5yZWNvZ25p
emVkIGludGVydmFsIHR5cG1vZDogJWQiLCB0eXBtb2QpOworCQkJZXJlcG9ydChFUlJPUiwK
KwkJCQkJKGVycmNvZGUoRVJSQ09ERV9JTlZBTElEX1BBUkFNRVRFUl9WQUxVRSksCisJCQkJ
CSBlcnJtc2coInVucmVjb2duaXplZCBpbnRlcnZhbCB0eXBtb2Q6ICVkIiwgdHlwbW9kKSkp
OwogCiAJCS8qIE5lZWQgdG8gYWRqdXN0IHN1Yi1zZWNvbmQgcHJlY2lzaW9uPyAqLwogCQlp
ZiAocHJlY2lzaW9uICE9IElOVEVSVkFMX0ZVTExfUFJFQ0lTSU9OKQpkaWZmIC0tZ2l0IGEv
c3JjL3BsL3BscGdzcWwvc3JjL3BsX2dyYW0ueSBiL3NyYy9wbC9wbHBnc3FsL3NyYy9wbF9n
cmFtLnkKaW5kZXggNWUxNGEyZDczMDIuLjM3Nzg1ZjU4Y2MyIDEwMDY0NAotLS0gYS9zcmMv
cGwvcGxwZ3NxbC9zcmMvcGxfZ3JhbS55CisrKyBiL3NyYy9wbC9wbHBnc3FsL3NyYy9wbF9n
cmFtLnkKQEAgLTM5Myw3ICszOTMsOSBAQCBjb21wX29wdGlvbgkJOiAnIycgS19PUFRJT04g
S19EVU1QCiAJCQkJCQllbHNlIGlmIChzdHJjbXAoJDMsICJvZmYiKSA9PSAwKQogCQkJCQkJ
CXBscGdzcWxfY3Vycl9jb21waWxlLT5wcmludF9zdHJpY3RfcGFyYW1zID0gZmFsc2U7CiAJ
CQkJCQllbHNlCi0JCQkJCQkJZWxvZyhFUlJPUiwgInVucmVjb2duaXplZCBwcmludF9zdHJp
Y3RfcGFyYW1zIG9wdGlvbiAlcyIsICQzKTsKKwkJCQkJCQllcmVwb3J0KEVSUk9SLAorCQkJ
CQkJCQkJKGVycmNvZGUoRVJSQ09ERV9TWU5UQVhfRVJST1IpLAorCQkJCQkJCQkJIGVycm1z
ZygidW5yZWNvZ25pemVkICVzIG9wdGlvbiBcIiVzXCIiLCAicHJpbnRfc3RyaWN0X3BhcmFt
cyIsICQzKSkpOwogCQkJCQl9CiAJCQkJfCAnIycgS19WQVJJQUJMRV9DT05GTElDVCBLX0VS
Uk9SCiAJCQkJCXsK

--------------7nN01B80S1J3FmnI0iSpBOey--