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

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: proposal: possibility to read dumped table's name from file
Дата
Msg-id CAOuzzgo=jCedUd9imehf+DtWPaHXG0K4JVDswJ35Yt=MZTkweQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: possibility to read dumped table's name from file  (Daniel Gustafsson <daniel@yesql.se>)
Ответы Re: proposal: possibility to read dumped table's name from file
Список pgsql-hackers
Дерево обсуждения
Greetings,

On Tue, Jul 13, 2021 at 16:44 Daniel Gustafsson <daniel@yesql.se> wrote:
> On 13 Jul 2021, at 18:14, Tomas Vondra <tomas.vondra@enterprisedb.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: proposal: possibility to read dumped table's name from file
Следующее
От: "Euler Taveira"
Дата:
Сообщение: Re: row filtering for logical replication