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
