Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote
Date
Msg-id 1317bb5e-3251-42c3-8874-31fb400398f9@dunslane.net
Whole thread Raw
In response to Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote
Re: getting "shell command argument contains a newline or carriage return:" error with pg_dumpall when db name have new line in double quote
List pgsql-hackers
On 2025-03-28 Fr 10:43 AM, Nathan Bossart wrote:
> On Fri, Mar 28, 2025 at 05:08:26PM +0530, Mahendra Singh Thalor wrote:
>> Here, I am attaching updated patches for review.
>>
>> v04_001* has the changes for CREATE DATABASE/ROLE/USER and
>> v04_002* has the changes into pg_upgrade to give ALERTS for invalid names.
> In general, +1 for these changes.  Thanks for picking this up.
>
> If these are intended for v18, we probably should have a committer
> attached to it soon.  I'm not confident that I'll have time for it,
> unfortunately.
>
> +    /* Report error if dbname have newline or carriage return in name. */
> +    if (strpbrk(dbname, "\n\r"))
> +        ereport(ERROR,
> +                (errcode(ERRCODE_INVALID_PARAMETER_VALUE)),
> +                errmsg("database name contains a newline or carriage return character"),
> +                errhint("newline or carriage return character is not allowed in database name"));
>
> I think it would be better to move this to a helper function instead of
> duplicating this code in several places.


The latest patches do that, but I'm not really sure it's an improvement, 
nor that define.c is the right place for it (everything else there works 
on a defElem)


>
> Taking a step back, are we sure that 1) this is the right place to do these
> checks and 2) we shouldn't apply the same restrictions to all names?  I'm
> wondering if it would be better to add these checks to the grammar instead
> of trying to patch up all the various places they are used in the tree.
>

Maybe. I don't think there is time for that for v18, so we'd have to 
defer this for now. I can live with that - it's been like this for a 
long time.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Update Unicode data to Unicode 16.0.0
Next
From: Tom Lane
Date:
Subject: Re: Removing unneeded self joins