Re: Non-text mode for pg_dumpall - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Non-text mode for pg_dumpall
Date
Msg-id 4ef51faa-993f-46ea-9e68-7baf736c07b8@dunslane.net
Whole thread Raw
In response to Re: Non-text mode for pg_dumpall  (jian he <jian.universality@gmail.com>)
Responses Re: Non-text mode for pg_dumpall
List pgsql-hackers
On 2025-03-12 We 3:03 AM, jian he wrote:
> On Wed, Mar 12, 2025 at 1:06 AM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>> Hello,
>>
>> On 2025-Mar-11, Mahendra Singh Thalor wrote:
>>
>>> In map.dat file, I tried to fix this issue by adding number of characters
>>> in dbname but as per code comments, as of now, we are not supporting \n\r
>>> in dbnames so i removed handling.
>>> I will do some more study to fix this issue.
>> Yeah, I think this is saying that you should not consider the contents
>> of map.dat as a shell string.  After all, you're not going to _execute_
>> that file via the shell.
>>
>> Maybe for map.dat you need to escape such characters somehow, so that
>> they don't appear as literal newlines/carriage returns.
>>
> I am confused.
> currently pg_dumpall plain format will abort when encountering dbname
> containing newline.
> the left dumped plain file does not contain all the cluster databases data.
>
>
> if pg_dumpall non-text format aborts earlier,
> it's aligned with pg_dumpall plain format?
> it's also an improvement since aborts earlier, nothing will be dumped?
>
>
> am i missing something?
>
>

I think we should fix that.

But for the current proposal, Álvaro and I were talking this morning, 
and we thought the simplest thing here would be to have the one line 
format and escape NL/CRs in the database name.


cheers


andrew

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




pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Introduce "log_connection_stages" setting.
Next
From: Nathan Bossart
Date:
Subject: remove open-coded popcount in acl.c