Greetings, * Tomas Vondra (tomas.von...@enterprisedb.com) wrote: > On 7/13/21 10:55 PM, Stephen Frost wrote: > >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.
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
signature.asc
Description: PGP signature