Date: Mon, 13 Jul 2020 09:32:04 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
	vignesh C <vignesh21@gmail.com>, pgsql-hackers@postgresql.org
Subject: Re: proposal: possibility to read dumped table's name from file
Message-ID: <20200713143204.GE23581@telsasoft.com>
References: 
 <CAFj8pRBP105Qa=2q9MEy_PWmCZGaWd4nt4nB2Gv8WgBO7UbkwA@mail.gmail.com>
 <20200609223042.GF26811@telsasoft.com>
 <CAFj8pRDk6EQGpbVO5tOsDvNnw41wmYWS7-w5Ym8gyRjvfoZ64g@mail.gmail.com>
 <20200701212452.GF4107@telsasoft.com>
 <20200705203119.GT4107@telsasoft.com>
 <CAFj8pRCCJ1vqDREwK41tbRX8k96VSAWFe9uOCCAmLJ8cwJC4Vw@mail.gmail.com>
 <CAFj8pRCRQOWLm2LrWcbkcm1Dx7yTuLks1_2VrTJO3PARDNXO3w@mail.gmail.com>
 <CALDaNm1iGfcBquWQEhCg5horyMROZc0x3_tQw-v=3hr8MxtOoA@mail.gmail.com>
 <CAFj8pRDU-CsvKjxEZ=SvuVjymFSEdS1pgLzxB7RTWSWnnqcLAA@mail.gmail.com>
 <F6674FF0-5800-4AED-9DC7-13C475707241@yesql.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F6674FF0-5800-4AED-9DC7-13C475707241@yesql.se>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

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