MIME-Version: 1.0
References: 
 <CAAZLFmRK+XFp=mqCeruyNVkqGq5mH45CP+e-8oNttPRtLuB5eQ@mail.gmail.com>
 <ee96443a-72f3-4a12-8ba7-326069fd1c14@eisentraut.org>
 <3793879.1751492926@sss.pgh.pa.us>
In-Reply-To: <3793879.1751492926@sss.pgh.pa.us>
From: Jianghua Yang <yjhjstz@gmail.com>
Date: Sat, 5 Jul 2025 09:58:09 -0700
Message-ID: 
 <CAAZLFmTtupwxA33fxVQ69AXG03RjXcoiEmd2soNSAk=Gc4ADkg@mail.gmail.com>
Subject: Re: [PATCH] initdb: Treat empty -U argument as unset username
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter@eisentraut.org>,
 pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000000b584006393186ee"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAZLFmTtupwxA33fxVQ69AXG03RjXcoiEmd2soNSAk%3DGc4ADkg%40mail.gmail.com>
Precedence: bulk

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

Hello Daniel, Tom lane

I wanted to ask if this patch can be merged first, as it seems to be a
separate issue different from the aclitem parsing problem Tom discussed in
https://www.postgresql.org/message-id/3792884.1751492172%40sss.pgh.pa.us
<https://www.google.com/url?source=3Dgmail&sa=3DD&sa=3DE&q=3Dhttps://www.po=
stgresql.org/message-id/3792884.1751492172%2540sss.pgh.pa.us>
.

Best regards,
Jianghua


Tom Lane <tgl@sss.pgh.pa.us> =E4=BA=8E2025=E5=B9=B47=E6=9C=882=E6=97=A5=E5=
=91=A8=E4=B8=89 14:48=E5=86=99=E9=81=93=EF=BC=9A

> Peter Eisentraut <peter@eisentraut.org> writes:
> > ... The aclitem parsing ends up in getid()
> > in src/backend/utils/adt/acl.c, which thinks that an input string
> > consisting entirely of "" is an escaped double quote.
>
> Yeah, that is definitely broken, and also it occurs to me that this
> coding is not robust in the face of non-ASCII identifiers (since
> the behavior of isalnum is unportable in that case).  I've posted
> a draft patch for that in a separate thread [1].
>
> > Maybe it's worth fixing that, and making putid() also print empty user
> > names correspondingly.
>
> putid() prints an empty name as an empty string, which seems fine
> at least at this level.
>
> > Alternatively, it's the fault of initdb that it constructs aclitem
> > values that don't follow the aclitem-specific quoting rules.
>
> With the patch at [1], initdb -U '' still fails at the same place,
> but now with
>
> FATAL:  a name must follow the "/" sign at character 72
>
> which is a consequence of getid()'s output not distinguishing
> "I found nothing" from "I found an empty string".  Now if we
> cared to support empty identifiers, we could make some more
> revisions here so that those were consistently represented as
> "" rather than nothing.  But I fail to see that that's a useful
> expenditure of time: we're never going to allow empty names.
>
> > Another thought is, if we don't allow zero-length names, shouldn't
> > namein() reject empty input strings?
>
> I'm inclined to think not.  It's introducing too much of a gotcha
> for too little return.  As a perhaps-not-quite-exact analogy,
> NULL::name also doesn't correspond to any identifier you can spell
> in SQL; but we're not going to try to forbid that value.  So there
> is at least one value of type "name" that isn't valid in SQL, and
> I don't see why ''::name can't be another.
>
>                         regards, tom lane
>
> [1]
> https://www.postgresql.org/message-id/3792884.1751492172%40sss.pgh.pa.us
>

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

<div dir=3D"ltr"><div class=3D"Znr6db">Hello Daniel, Tom lane<br><br>I want=
ed to ask if this patch can be merged first, as it seems to be a separate i=
ssue different from the aclitem parsing problem Tom discussed in <a href=3D=
"https://www.google.com/url?source=3Dgmail&amp;sa=3DD&amp;sa=3DE&amp;q=3Dht=
tps://www.postgresql.org/message-id/3792884.1751492172%2540sss.pgh.pa.us">h=
ttps://www.postgresql.org/message-id/3792884.1751492172%40sss.pgh.pa.us</a>=
.<br><br>Best regards,<br>Jianghua</div><br></div><br><div class=3D"gmail_q=
uote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Tom Lane =
&lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; =E4=BA=
=8E2025=E5=B9=B47=E6=9C=882=E6=97=A5=E5=91=A8=E4=B8=89 14:48=E5=86=99=E9=81=
=93=EF=BC=9A<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Pet=
er Eisentraut &lt;<a href=3D"mailto:peter@eisentraut.org" target=3D"_blank"=
>peter@eisentraut.org</a>&gt; writes:<br>
&gt; ... The aclitem parsing ends up in getid() <br>
&gt; in src/backend/utils/adt/acl.c, which thinks that an input string <br>
&gt; consisting entirely of &quot;&quot; is an escaped double quote.<br>
<br>
Yeah, that is definitely broken, and also it occurs to me that this<br>
coding is not robust in the face of non-ASCII identifiers (since<br>
the behavior of isalnum is unportable in that case).=C2=A0 I&#39;ve posted<=
br>
a draft patch for that in a separate thread [1].<br>
<br>
&gt; Maybe it&#39;s worth fixing that, and making putid() also print empty =
user <br>
&gt; names correspondingly.<br>
<br>
putid() prints an empty name as an empty string, which seems fine<br>
at least at this level.<br>
<br>
&gt; Alternatively, it&#39;s the fault of initdb that it constructs aclitem=
 <br>
&gt; values that don&#39;t follow the aclitem-specific quoting rules.<br>
<br>
With the patch at [1], initdb -U &#39;&#39; still fails at the same place,<=
br>
but now with<br>
<br>
FATAL:=C2=A0 a name must follow the &quot;/&quot; sign at character 72<br>
<br>
which is a consequence of getid()&#39;s output not distinguishing<br>
&quot;I found nothing&quot; from &quot;I found an empty string&quot;.=C2=A0=
 Now if we<br>
cared to support empty identifiers, we could make some more<br>
revisions here so that those were consistently represented as<br>
&quot;&quot; rather than nothing.=C2=A0 But I fail to see that that&#39;s a=
 useful<br>
expenditure of time: we&#39;re never going to allow empty names.<br>
<br>
&gt; Another thought is, if we don&#39;t allow zero-length names, shouldn&#=
39;t <br>
&gt; namein() reject empty input strings?<br>
<br>
I&#39;m inclined to think not.=C2=A0 It&#39;s introducing too much of a got=
cha<br>
for too little return.=C2=A0 As a perhaps-not-quite-exact analogy,<br>
NULL::name also doesn&#39;t correspond to any identifier you can spell<br>
in SQL; but we&#39;re not going to try to forbid that value.=C2=A0 So there=
<br>
is at least one value of type &quot;name&quot; that isn&#39;t valid in SQL,=
 and<br>
I don&#39;t see why &#39;&#39;::name can&#39;t be another.<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>
<br>
[1] <a href=3D"https://www.postgresql.org/message-id/3792884.1751492172%40s=
ss.pgh.pa.us" rel=3D"noreferrer" target=3D"_blank">https://www.postgresql.o=
rg/message-id/3792884.1751492172%40sss.pgh.pa.us</a><br>
</blockquote></div>

--0000000000000b584006393186ee--