public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jianghua Yang <[email protected]>
To: Tom Lane <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] initdb: Treat empty -U argument as unset username
Date: Sat, 5 Jul 2025 09:58:09 -0700
Message-ID: <CAAZLFmTtupwxA33fxVQ69AXG03RjXcoiEmd2soNSAk=Gc4ADkg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAAZLFmRK+XFp=mqCeruyNVkqGq5mH45CP+e-8oNttPRtLuB5eQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>

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-i...;
.

Best regards,
Jianghua


Tom Lane <[email protected]> 于2025年7月2日周三 14:48写道：

> 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: <CAAZLFmTtupwxA33fxVQ69AXG03RjXcoiEmd2soNSAk=Gc4ADkg@mail.gmail.com>

* 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