MIME-Version: 1.0
References: 
 <CAAZLFmRK+XFp=mqCeruyNVkqGq5mH45CP+e-8oNttPRtLuB5eQ@mail.gmail.com>
 <CAKFQuwbVK=oANp9XLdQknd7o9jJOUFQanUtG3QAh-3kuaM5tJw@mail.gmail.com>
 <CAAZLFmSKrcovMSauueWg=8VdZN-fHPH2ZengZRKA8AfgST6o6w@mail.gmail.com>
 <CAKFQuwaCPkb8=2_V3121Ei0MBrg02FLRNQbcAcyzCO3dAha=Gw@mail.gmail.com>
 <CABV9wwOOpOijL9sY03KV3WNvgMxVFsyfvfYbfy2MYfn40z0yyQ@mail.gmail.com>
 <0231C713-50C8-4BE5-B7C8-106F57A79655@yesql.se>
In-Reply-To: <0231C713-50C8-4BE5-B7C8-106F57A79655@yesql.se>
From: Jianghua Yang <yjhjstz@gmail.com>
Date: Wed, 2 Jul 2025 06:52:09 -0700
Message-ID: 
 <CAAZLFmSY_s6TOsiTwjzqrc2Y4uShATuWcEEN8O8cdtpkS=zfLg@mail.gmail.com>
Subject: Re: [PATCH] initdb: Treat empty -U argument as unset username
To: daniel@yesql.se
Cc: Robert Treat <rob@xzilla.net>,
 "David G. Johnston" <david.g.johnston@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Content-Type: multipart/mixed; boundary="00000000000062d7630638f29395"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAZLFmSY_s6TOsiTwjzqrc2Y4uShATuWcEEN8O8cdtpkS%3DzfLg%40mail.gmail.com>
Precedence: bulk

--00000000000062d7630638f29395
Content-Type: multipart/alternative; boundary="00000000000062d7620638f29393"

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

Hi hackers,

Based on the suggestion that we should explicitly reject empty usernames
instead of silently falling back, I=E2=80=99ve updated the patch accordingl=
y.

### Changes in v2:

- `initdb` now errors out immediately if the `-U` or `--username` argument
is an empty string.
- The error message is:

      superuser name must not be empty

- A regression test is added to `src/bin/initdb/t/001_initdb.pl` to verify
that the case `initdb -U ''` fails as expected.

This approach avoids any ambiguity about whether an empty username is
valid, and fails early with a clear message. It also brings consistency
with existing checks, such as the one disallowing superuser names starting
with `pg_`.

Let me know if this looks acceptable or if further refinement is needed.

Patch attached.

Best regards,
Jianghua Yang

Daniel Gustafsson <daniel@yesql.se> =E4=BA=8E2025=E5=B9=B47=E6=9C=882=E6=97=
=A5=E5=91=A8=E4=B8=89 00:16=E5=86=99=E9=81=93=EF=BC=9A

> > On 2 Jul 2025, at 06:31, Robert Treat <rob@xzilla.net> wrote:
>
> > FWIW, I tend to agree with David; I feel like if a user passes in -U,
> > there was probably a reason, and a good error message would be more
> > useful in clarifying things rather than blindly pushing forward with
> > potentially the wrong thing.
>
> Agreed, and it's not even clear that the previous code was intentionally
> trying
> to allow an empty -U. An improved error message would be a good patch
> though.
>
> --
> Daniel Gustafsson
>
>

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

<div dir=3D"ltr">Hi hackers,<br><br>Based on the suggestion that we should =
explicitly reject empty usernames instead of silently falling back, I=E2=80=
=99ve updated the patch accordingly.<br><br>### Changes in v2:<br><br>- `in=
itdb` now errors out immediately if the `-U` or `--username` argument is an=
 empty string.<br>- The error message is:<br>=C2=A0 <br>=C2=A0 =C2=A0 =C2=
=A0 superuser name must not be empty<br><br>- A regression test is added to=
 `src/bin/initdb/t/<a href=3D"http://001_initdb.pl">001_initdb.pl</a>` to v=
erify that the case `initdb -U &#39;&#39;` fails as expected.<br><br>This a=
pproach avoids any ambiguity about whether an empty username is valid, and =
fails early with a clear message. It also brings consistency with existing =
checks, such as the one disallowing superuser names starting with `pg_`.<br=
><br>Let me know if this looks acceptable or if further refinement is neede=
d.<br><br>Patch attached.<br><br>Best regards, =C2=A0<br>Jianghua Yang</div=
><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" clas=
s=3D"gmail_attr">Daniel Gustafsson &lt;<a href=3D"mailto:daniel@yesql.se">d=
aniel@yesql.se</a>&gt; =E4=BA=8E2025=E5=B9=B47=E6=9C=882=E6=97=A5=E5=91=A8=
=E4=B8=89 00:16=E5=86=99=E9=81=93=EF=BC=9A<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">&gt; On 2 Jul 2025, at 06:31, Robert Treat &lt;<=
a href=3D"mailto:rob@xzilla.net" target=3D"_blank">rob@xzilla.net</a>&gt; w=
rote:<br>
<br>
&gt; FWIW, I tend to agree with David; I feel like if a user passes in -U,<=
br>
&gt; there was probably a reason, and a good error message would be more<br=
>
&gt; useful in clarifying things rather than blindly pushing forward with<b=
r>
&gt; potentially the wrong thing.<br>
<br>
Agreed, and it&#39;s not even clear that the previous code was intentionall=
y trying<br>
to allow an empty -U. An improved error message would be a good patch thoug=
h.<br>
<br>
--<br>
Daniel Gustafsson<br>
<br>
</blockquote></div>

--00000000000062d7620638f29393--

--00000000000062d7630638f29395
Content-Type: application/octet-stream;
	name="0001-initdb-Reject-empty-string-for-U-username-option.patch"
Content-Disposition: attachment;
	filename="0001-initdb-Reject-empty-string-for-U-username-option.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mcm0mogp0>
X-Attachment-Id: f_mcm0mogp0

RnJvbSA3NzMyNmEwMzBmZDJmZmE0YWUwMTJhYWUyODU0MGIzZDhmNWJkNGVmIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBKaWFuZ2h1YSBZYW5nIDx5amhqc3R6QGdtYWlsLmNvbT4KRGF0
ZTogV2VkLCAyIEp1bCAyMDI1IDA2OjQ4OjQ4IC0wNzAwClN1YmplY3Q6IFtQQVRDSF0gaW5pdGRi
OiBSZWplY3QgZW1wdHkgc3RyaW5nIGZvciAtVS8tLXVzZXJuYW1lIG9wdGlvbgoKUHJldmlvdXNs
eSwgcGFzc2luZyBhbiBlbXB0eSBzdHJpbmcgdG8gdGhlIC1VIG9yIC0tdXNlcm5hbWUgb3B0aW9u
CihlLmcuLCBgaW5pdGRiIC1VICcnYCkgd291bGQgY2F1c2UgY29uZnVzaW5nIGVycm9ycyBkdXJp
bmcgYm9vdHN0cmFwLAphcyBpbml0ZGIgYXR0ZW1wdGVkIHRvIGNyZWF0ZSBhIHJvbGUgd2l0aCBh
biBlbXB0eSBuYW1lLgoKVGhpcyBwYXRjaCBhZGRzIGFuIGV4cGxpY2l0IGNoZWNrIGZvciBlbXB0
eSB1c2VybmFtZXMgYW5kIGV4aXRzCmltbWVkaWF0ZWx5IHdpdGggYSBjbGVhciBlcnJvciBtZXNz
YWdlLgoKQSB0ZXN0IGNhc2UgaXMgYWRkZWQgdG8gdmVyaWZ5IHRoYXQgaW5pdGRiIGZhaWxzIHdo
ZW4gLVUgaXMgZ2l2ZW4gYW4KZW1wdHkgc3RyaW5nLgotLS0KIHNyYy9iaW4vaW5pdGRiL2luaXRk
Yi5jICAgICAgICB8IDUgKysrKysKIHNyYy9iaW4vaW5pdGRiL3QvMDAxX2luaXRkYi5wbCB8IDQg
KysrKwogMiBmaWxlcyBjaGFuZ2VkLCA5IGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9zcmMv
YmluL2luaXRkYi9pbml0ZGIuYyBiL3NyYy9iaW4vaW5pdGRiL2luaXRkYi5jCmluZGV4IDYyYmJk
MDhkOWY2Li4wZmQ2N2FkNDk2ZiAxMDA2NDQKLS0tIGEvc3JjL2Jpbi9pbml0ZGIvaW5pdGRiLmMK
KysrIGIvc3JjL2Jpbi9pbml0ZGIvaW5pdGRiLmMKQEAgLTMyOTEsNiArMzI5MSwxMSBAQCBtYWlu
KGludCBhcmdjLCBjaGFyICphcmd2W10pCiAJCQkJcHdwcm9tcHQgPSB0cnVlOwogCQkJCWJyZWFr
OwogCQkJY2FzZSAnVSc6CisJCQkJaWYgKG9wdGFyZ1swXSA9PSAnXDAnKQorCQkJCXsKKwkJCQkJ
cGdfbG9nX2Vycm9yKCJzdXBlcnVzZXIgbmFtZSBtdXN0IG5vdCBiZSBlbXB0eSIpOworCQkJCQll
eGl0KDEpOworCQkJCX0KIAkJCQl1c2VybmFtZSA9IHBnX3N0cmR1cChvcHRhcmcpOwogCQkJCWJy
ZWFrOwogCQkJY2FzZSAnZCc6CmRpZmYgLS1naXQgYS9zcmMvYmluL2luaXRkYi90LzAwMV9pbml0
ZGIucGwgYi9zcmMvYmluL2luaXRkYi90LzAwMV9pbml0ZGIucGwKaW5kZXggMTVkZDEwY2U0MGEu
LjY3ZWI1MzA2NGY2IDEwMDY0NAotLS0gYS9zcmMvYmluL2luaXRkYi90LzAwMV9pbml0ZGIucGwK
KysrIGIvc3JjL2Jpbi9pbml0ZGIvdC8wMDFfaW5pdGRiLnBsCkBAIC0zNyw2ICszNywxMCBAQCBj
b21tYW5kX2ZhaWxzKAogY29tbWFuZF9mYWlscyhbICdpbml0ZGInLCAnLS11c2VybmFtZScgPT4g
J3BnX3Rlc3QnLCAkZGF0YWRpciBdLAogCSdyb2xlIG5hbWVzIGNhbm5vdCBiZWdpbiB3aXRoICJw
Z18iJyk7CiAKK2NvbW1hbmRfZmFpbHMoCisJWyAnaW5pdGRiJywgJy1VJywgJycsICRkYXRhZGly
IF0sCisJJ2VtcHR5IHVzZXJuYW1lIG5vdCBhbGxvd2VkJyk7CisKIG1rZGlyICRkYXRhZGlyOwog
CiAjIG1ha2Ugc3VyZSB3ZSBydW4gb25lIHN1Y2Nlc3NmdWwgdGVzdCB3aXRob3V0IGEgVFogc2V0
dGluZyBzbyB3ZSB0ZXN0Ci0tIAoyLjM5LjUgKEFwcGxlIEdpdC0xNTQpCgo=
--00000000000062d7630638f29395--