Greetings,
* Tomas Vondra (tomas.vondra@enterprisedb.com) wrote:
> On 7/13/21 10:55 PM, Stephen Frost wrote:
> >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.
The simplest possible format isn't going to work with all the different
pg_dump options and it still isn't going to be 'simple' since it needs
to work with the flexibility that we have in what we support for object
names, and is still going to require people write a new parser and
generator for it instead of using something existing.
I don't know that the options that I suggested previously would
definitely work or not but they at least would allow other projects like
pgAdmin to leverage existing code for parsing and generating these
config files. I'm not completely against inventing something new, but
I'd really prefer that we at least try to make something existing work
first before inventing something new that everyone is going to have to
deal with. If we do invent a new thing for $reasons, then we should
really look at what exists today and try to design it properly instead
of just throwing something together and formally document it because
it's absolutely going to become a standard of sorts that people are
going to almost immediately write their own parsers/generators in
various languages for.
Thanks,
Stephen
