Hi st 25. 11. 2020 v 19:25 odesÃlatel Dean Rasheed <dean.a.rash...@gmail.com> napsal:
> On Thu, 19 Nov 2020 at 19:57, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > > > minor update - fixed handling of processing names with double quotes > inside > > > > I see this is marked RFC, but reading the thread it doesn't feel like > we have reached consensus on the design for this feature. > > I agree that being able to configure pg_dump via a config file would > be very useful, but the syntax proposed here feels much more like a > hacked-up syntax designed to meet this one use case, rather than a > good general-purpose design that can be easily extended. > Nobody sent a real use case for introducing the config file. There was a discussion about formats, and you introduce other dimensions and variability. But I don't understand why? What is a use case? What is a benefit against command line, or libpq variables? And why should config files be better as a solution for limited length of command line, when I need to dump thousands of tables exactly specified? Regards Pavel > IMO, a pg_dump config file should be able to specify all options > currently supported through the command line, and vice versa (subject > to command line length limits), with a single common code path for > handling options. That way, any new options we add will work on the > command line and in config files. Likewise, the user should only need > to learn one set of options, and have the choice of specifying them on > the command line or in a config file (or a mix of both). > > I can imagine eventually supporting multiple different file formats, > each just being a different representation of the same data, so > perhaps this could work with 2 new options: > > --option-file-format=plain|yaml|json|... > --option-file=filename > > with "plain" being the default initial implementation, which might be > something like our current postgresql.conf file format. > > Also, I think we should allow multiple "--option-file" arguments > (e.g., to list different object types in different files), and for a > config file to contain its own "--option-file" arguments, to allow > config files to include other config files. > > The current design feels far too limited to me, and requires new code > and new syntax to be added each time we extend it, so I'm -1 on this > patch as it stands. This new syntax tries to be consistent and simple. It really doesn't try to implement an alternative configuration file for pg_dump. The code is simple and can be easily extended. What are the benefits of supporting multiple formats? > Regards, > Dean >
