On 7/13/21 10:55 PM, Stephen Frost wrote:
Greetings,
On Tue, Jul 13, 2021 at 16:44 Daniel Gustafsson <dan...@yesql.se
<mailto:dan...@yesql.se>> wrote:
> On 13 Jul 2021, at 18:14, Tomas Vondra
<tomas.von...@enterprisedb.com
<mailto:tomas.von...@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.
Sure. Which is why I'm advocating for the simplest possible format (and
not expanding the scope of this patch beyond filtering), because that
makes this kind of processing simpler.
> 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.
I wasn't really basing this on a single customer - that was merely an
example, of course. FWIW Justin Pryzby already stated having to use some
more complex format would likely mean they would not use the feature, so
that's another data point to consider.
FWIW I believe it's clear what my opinions on this topic are. Repeating
that seems a bit pointless, so I'll step aside and let this thread move
forward in whatever direction.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
