Re: proposal: possibility to read dumped table's name from file

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: proposal: possibility to read dumped table's name from file
Date: 2020-07-13 14:32:04
Message-ID: 20200713143204.GE23581@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 13, 2020 at 12:04:09PM +0200, Daniel Gustafsson wrote:
> Sorry for jumping in late, but thinking about this extension to pg_dump:
> doesn't it make more sense to use an existing file format like JSON for this,
> given that virtually all devops/cd/etc tooling know about JSON already?
>
> Considering its application and the problem space, I'd expect users to generate
> this file rather than handcraft it with 10 rows of content, and standard file
> formats help there.

I mentioned having tested this patch as we would use it. But it's likely I
*wouldn't* use it if the format was something which required added complexity
to pipe in from an existing shell script.

> At the very least it seems limiting to not include a file format version
> identifier since we'd otherwise risk running into backwards compat issues
> should we want to expand on this in the future.

Maybe .. I'm not sure. The patch would of course be extended to handle
additional include/exclude options. Is there any other future behavior we
might reasonably anticipate ?

If at some point we wanted to support another file format, maybe it would look
like: --format=v2:filters.txt (or maybe the old one would be v1:filters.txt)

--
Justin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-07-13 14:37:36 Re: output columns of \dAo and \dAp
Previous Message David Rowley 2020-07-13 14:25:31 Re: Default setting for enable_hashagg_disk