On 7/13/21 10:55 PM, Stephen Frost wrote:
> Greetings,
>
> On Tue, Jul 13, 2021 at 16:44 Daniel Gustafsson <daniel@yesql.se
> <mailto:daniel@yesql.se>> wrote:
>
> > On 13 Jul 2021, at 18:14, Tomas Vondra
> <tomas.vondra@enterprisedb.com
> <mailto: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.
>
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