st 25. 11. 2020 v 21:00 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes: > st 25. 11. 2020 v 19:25 odesílatel Dean Rasheed <dean.a.rasheed@gmail.com> > napsal: >> 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.
> 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?
Because next week somebody will want to dump thousands of functions selected by name, or schemas selected by name, etc etc. I agree with the position that we don't want a single-purpose solution. The idea that the syntax should match the command line switch syntax seems reasonable, though I'm not wedded to it. (One thing to consider is how painful will it be for people to quote table names containing funny characters, for instance. On the command line, we largely depend on the shell's quoting behavior to solve that, but we'd not have that infrastructure when reading from a file.)
> What are the benefits of supporting multiple formats?
Yeah, that part of Dean's sketch seemed like overkill to me too.
I wasn't very excited about multiple switch files either, though depending on how the implementation is done, that could be simple enough to be in the might-as-well category.
One other point that I'm wondering about is that there's really no value in doing anything here until you get to some thousands of table names; as long as the list fits in the shell's command line length limit, you might as well just make a shell script file. Does pg_dump really have sane performance for that situation, or are we soon going to be fielding requests to make it not be O(N^2) in the number of listed tables?
Here is a fresh implementation. I used the name of a new option - "options-file". Looks more accurate than "config", but the name can be changed easily anytime.
Any short or long option can be read from this file in simple format - one option per line. Arguments inside double quotes can be multi lined. Row comments started by # and can be used everywhere.
The implementation is very generic - support of new options doesn't require change of this new part code. The parser can ignore white spaces almost everywhere, where it has sense.
The option should start with "-" or "--" in the options file too, because this is necessary for good detection if the option is short or long.
