Re: proposal: possibility to read dumped table's name from file

Hi

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.

Regards

Pavel



>                         regards, tom lane
>