Re: [PATCH] initdb: Treat empty -U argument as unset username

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=gmail&sa=D&sa=E&q=https://www.postgresql.org/message-id/3792884.1751492172%2540sss.pgh.pa.us>
.

Best regards,
Jianghua

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 于2025年7月2日周三 14:48写道：

> Peter Eisentraut <peter(at)eisentraut(dot)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
>