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 <t...@sss.pgh.pa.us> 于2025年7月2日周三 14:48写道： > Peter Eisentraut <pe...@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 >
