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

Greetings,

On Tue, Jul 13, 2021 at 16:44 Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:

> > On 13 Jul 2021, at 18:14, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
> wrote:
>
> > FWIW I don't understand why would they need to write parsers.
>
> It's quite common to write unit tests for VM recipes/playbooks wheen using
> tools like Chef etc, parsing and checking the installed/generated files is
> part
> of that. This would be one very real use case for writing a parser.

Consider pgAdmin and the many other tools which essentially embed pg_dump
and pg_restore. There’s no shortage of use cases for a variety of tools to
be able to understand, read, parse, generate, rewrite, and probably do
more, with such a pg_dump/restore config file.

> I think the case when the filter file needs to be modified is rather rare
> - it certainly is not what the original use case Pavel tried to address
> needs. (I know that customer and the filter would be generated and used for
> a single dump.)
>
> I'm not convinced that basing design decisions on a single customer
> reference
> who only want to use the code once is helpful.

Agreed.

Thanks,

Stephen

>