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 1uWy1u-0041Dt-F2 for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Jul 2025 14:01:42 +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 1uWy1s-001VO0-Ib for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Jul 2025 14:01:41 +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 1uWy1s-001VNH-56 for pgsql-hackers@lists.postgresql.org; Wed, 02 Jul 2025 14:01:40 +0000 Received: from smtp.outgoing.loopia.se ([93.188.3.37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uWy1q-005JUI-2E for pgsql-hackers@lists.postgresql.org; Wed, 02 Jul 2025 14:01:40 +0000 Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id A49FD3CE07F for ; Wed, 02 Jul 2025 16:01:37 +0200 (CEST) Received: from s981.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id 910653CDF40; Wed, 02 Jul 2025 16:01:37 +0200 (CEST) Received: from s474.loopia.se (unknown [172.22.191.6]) by s981.loopia.se (Postfix) with ESMTP id 8E46522B17BC; Wed, 02 Jul 2025 16:01:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=6.2 tests=[ALL_TRUSTED=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1] autolearn=disabled Authentication-Results: s474.loopia.se (amavisd-new); dkim=pass (2048-bit key) header.d=yesql.se Received: from s899.loopia.se ([172.22.191.5]) by s474.loopia.se (s474.loopia.se [172.22.190.14]) (amavisd-new, port 10024) with UTF8LMTP id CACYRYs692xt; Wed, 2 Jul 2025 16:01:37 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: daniel@yesql.se X-Loopia-Originating-IP: 89.255.232.236 Received: from smtpclient.apple (customer-89-255-232-236.stosn.net [89.255.232.236]) (Authenticated sender: daniel@yesql.se) by s899.loopia.se (Postfix) with ESMTPSA id 2E3EB2C8BAE6; Wed, 02 Jul 2025 16:01:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yesql.se; s=loopiadkim1707475645; t=1751464897; bh=3xPHGtJpChfuXkR8oLPmyHs1FGlaExH38jUNtDu8MvU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=vpWD2SzjRvHtfdec4W+2oP+7wZjRJCTKhW+B+FFHnmw4FUAJ7tk7hkQoaN/FQC+eL U0F7jDB3bl4OKPIOfU9jAqeWTZKYCXZXCe20JwwPmhyXlNDGqhNg8Ts2CCS3gPBeSv LFnl0vzsTBx0xIT3Jg2a5btJ431rEFO2Hx/H3LDXb6f2H+yObTHQL+P7T97cf0jEiX +8bmUuuWoTty+29OMCpEg0AjL/KG/7aoBZorFyzTgo4DegJ7rra9TAyjHPEKJvovwl 7LZ1Rm7E5PWwgwSx1kn3Uv5Rck+68Zn6qTBQimQOQexY+STPxwHp0zMFLz0S5AkGe/ jLefteHqScPNg== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.2\)) Subject: Re: [PATCH] initdb: Treat empty -U argument as unset username From: Daniel Gustafsson In-Reply-To: Date: Wed, 2 Jul 2025 16:01:26 +0200 Cc: Robert Treat , "David G. Johnston" , pgsql-hackers@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0231C713-50C8-4BE5-B7C8-106F57A79655@yesql.se> To: Jianghua Yang X-Mailer: Apple Mail (2.3776.700.51.11.2) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 2 Jul 2025, at 15:52, Jianghua Yang wrote: >=20 > Hi hackers, >=20 > Based on the suggestion that we should explicitly reject empty = usernames instead of silently falling back, I=E2=80=99ve updated the = patch accordingly. >=20 > ### Changes in v2: >=20 > - `initdb` now errors out immediately if the `-U` or `--username` = argument is an empty string. > - The error message is: > =20 > superuser name must not be empty >=20 > - A regression test is added to `src/bin/initdb/t/001_initdb.pl` to = verify that the case `initdb -U ''` fails as expected. >=20 > 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_`. >=20 > Let me know if this looks acceptable or if further refinement is = needed. + pg_log_error("superuser name must not be empty"); + exit(1); I would prefer pg_fatal() for this. -- Daniel Gustafsson