public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: Jianghua Yang <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] initdb: Treat empty -U argument as unset username
Date: Wed, 02 Jul 2025 17:48:46 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAAZLFmRK+XFp=mqCeruyNVkqGq5mH45CP+e-8oNttPRtLuB5eQ@mail.gmail.com>
<[email protected]>
Peter Eisentraut <[email protected]> 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
view thread (16+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] initdb: Treat empty -U argument as unset username
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox