Re: proposal: possibility to read dumped table's name from file - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: proposal: possibility to read dumped table's name from file
Date
Msg-id 0CDB1A7D-F3FB-4689-B452-9E95A8DC6B8C@yesql.se
Whole thread Raw
In response to Re: proposal: possibility to read dumped table's name from file  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: proposal: possibility to read dumped table's name from file  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
> 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.

> I think the case when the filter file needs to be modified is rather rare - it certainly is not what the original use
casePavel 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.  I hear what you're saying, but
I think this will see more diverse use cases than what we can foresee here.

--
Daniel Gustafsson        https://vmware.com/




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16583: merge join on tables with different DB collation behind postgres_fdw fails
Next
From: Daniel Gustafsson
Date:
Subject: Re: proposal: possibility to read dumped table's name from file