Re: WIP Patch: pg_dump structured - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP Patch: pg_dump structured
Date
Msg-id 1609797.1678654206@sss.pgh.pa.us
Whole thread Raw
In response to WIP Patch: pg_dump structured  (Attila Soki <pgsql@attilasoki.com>)
Responses Re: WIP Patch: pg_dump structured  (Attila Soki <pgsql@attilasoki.com>)
List pgsql-hackers
Attila Soki <pgsql@attilasoki.com> writes:
> This patch adds the structured output format to pg_dump.
> This format is a plaintext output split up into multiple files and the
> resulting small files are stored in a directory path based on the dumped object.

Won't this fail completely with SQL objects whose names aren't suitable
to be pathname components?  "A/B" is a perfectly good name so far as
SQL is concerned.  You could also have problems with collisions on
case-insensitive filesystems.

> This format can be restored by feeding its plaintext toc file (restore-dump.sql)
> to psql. The output is also suitable for manipulating the files with standard
> editing tools.

This seems a little contradictory: if you want to edit the individual
files, you'd have to also update restore-dump.sql, or else it's pointless.
It might make more sense to consider this as a write-only dump format
and not worry about whether it can be restored directly.

> What do you think of this feature, any chance it will be added to pg_dump once
> the patch is ready?

I'm not clear on how big the use-case is.  It's not really obvious to
me that this'd have any benefit over the existing plain-text dump
capability.  You can edit those files too, at least till the schema
gets too big for your editor.  (But if you've got many many thousand
SQL objects, a file-per-SQL-object directory will also be no fun to
deal with.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Attila Soki
Date:
Subject: WIP Patch: pg_dump structured
Next
From: Peter Smith
Date:
Subject: Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher