Re: Non-text mode for pg_dumpall
От | Andrew Dunstan |
---|---|
Тема | Re: Non-text mode for pg_dumpall |
Дата | |
Msg-id | 4ef51faa-993f-46ea-9e68-7baf736c07b8@dunslane.net обсуждение исходный текст |
Ответ на | Re: Non-text mode for pg_dumpall (jian he <jian.universality@gmail.com>) |
Ответы |
Re: Non-text mode for pg_dumpall
|
Список | 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 по дате отправления: