Re: Non-text mode for pg_dumpall

Mahendra Singh Thalor <mahi6run@gmail.com>

From: Mahendra Singh Thalor <mahi6run@gmail.com>

To: Álvaro Herrera <alvherre@alvh.no-ip.org>

Cc: jian he <jian.universality@gmail.com>, Srinath Reddy <srinath2133@gmail.com>, pgsql-hackers@lists.postgresql.org

Date: 2025-03-11T15:41:07Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Add non-text output formats to pg_dumpall
- 763aaa06f034 19 (unreleased) landed
Improve pg_dump/pg_dumpall help synopses and terminology
- dec6643487bb 18.0 cited
Non text modes for pg_dumpall, correspondingly change pg_restore
- 1495eff7bdb0 18.0 landed
Doc: manually break lines in wide UUID examples.
- a6524105d20b 18.0 cited

Attachments

v23_0001_move-common-code-of-pg_dumpall-and-pg_restore-to-new_file.patch (application/octet-stream) patch v23-0001
v23_0002_pg_dumpall-with-non-text_format-11th_march.patch (application/octet-stream) patch v23-0002

On Tue, 11 Mar 2025 at 20:12, Álvaro Herrera <alvherre@alvh.no-ip.org>
wrote:
>
> On 2025-Mar-11, Mahendra Singh Thalor wrote:
>
> > On Wed, 5 Mar 2025 at 20:42, Álvaro Herrera <alvherre@alvh.no-ip.org>
wrote:
>
> > > Okay, we should probably fix that, but I think the new map.dat file
your
> > > patch adds is going to make the problem worse, because it doesn't look
> > > like you handled that case in any particular way that would make it
not
> > > fail.
> >
> > As Jian also pointed out, we should not allow \n\r in dbnames. I am
> > keeping dbanames as single line names only.
>
> Ehm, did you get consensus on adding such a restriction?
>

Hi Alvaro,

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.

/*
>  * Append the given string to the shell command being built in the buffer,
>  * with shell-style quoting as needed to create exactly one argument.
>  *
>  * Forbid LF or CR characters, which have scant practical use beyond
> designing
>  * security breaches.  The Windows command shell is unusable as a conduit
> for
>  * arguments containing LF or CR characters.  A future major release should
>  * reject those characters in CREATE ROLE and CREATE DATABASE, because use
>  * there eventually leads to errors here.
>  *
>  * appendShellString() simply prints an error and dies if LF or CR appears.
>  * appendShellStringNoError() omits those characters from the result, and
>  * returns false if there were any.
>  */
> void
> appendShellString(PQExpBuffer buf, const char *str)


Sorry, in the v22 patches, I missed to use the "git add connectdb.c" file.
(Thanks Andrew for reporting this offline)

Here, I am attaching updated patches for review and testing.

-- 
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com