On 02.07.25 04:55, Jianghua Yang wrote:
> While working with `initdb`, I noticed that passing an empty string to
> the `-U` option (e.g., `initdb -U ''`) causes it to fail with a
> misleading error:
>
> performing post-bootstrap initialization ... 2025-07-01 19:48:42.006 PDT
> [14888] FATAL:role """ does not exist at character 72
>
> 2025-07-01 19:48:42.006 PDT [14888] STATEMENT:
>
> UPDATE pg_class SET relacl = (SELECT array_agg(a.acl) FROM(SELECT
> E'=r/""' as acl UNION SELECT unnest(pg_catalog.acldefault(CASE WHEN
> relkind = 'S' THEN 's'ELSE 'r' END::"char",10::oid)) ) as a) WHERE
> relkind IN ('r', 'v', 'm', 'S')AND relacl IS NULL;
>
> This happens because `initdb` accepts the empty string as a valid role
> name and attempts to use it as the database superuser, which is not
> intended and fails during bootstrap SQL.
I'll start by saying, of course an empty user name isn't going to work,
so we should reject it.
But let's dig a little deeper into why it fails. Observe the error:
FATAL:role """ does not exist at character 72
It thinks that the role name is `"` (a sole double-quote, not empty!).
Why is that?
This error comes from the literal
E'=r/""'
interpreted as an aclitem value. 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.
Maybe it's worth fixing that, and making putid() also print empty user
names correspondingly.
Alternatively, it's the fault of initdb that it constructs aclitem
values that don't follow the aclitem-specific quoting rules.
Another thought is, if we don't allow zero-length names, shouldn't
namein() reject empty input strings? Then this whole thing would fail
as postgres.bki is being loaded. (This is more hypothetical, since this
appears to break a number of other things.)
All of this is to say, it's worth looking at the actual cause and think
about if there are related problems, maybe other name patterns that we
don't handle well, instead of just papering over it at the top level.
