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

st 25. 11. 2020 v 21:00 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > st 25. 11. 2020 v 19:25 odesílatel Dean Rasheed <
> dean(dot)a(dot)rasheed(at)gmail(dot)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.)
>

This is not a problem with the current patch - and the last version of this
patch supports well obscure names.

There was a requirement for supporting all and future pg_dump options - ok
it can make sense. I have not a problem to use instead a line format

"option argument" or "long-option=argument"

This format - can it be a solution? I'll try to rewrite the parser for this
format.

It is implementable, but this is in collision with Stephen's requirement
for human well readable format designed for handy writing. There are
requests that have no intersection. Well readable format needs a more
complex parser. And machine generating in this format needs more fork -
generating flat file is more simple and more robust than generating JSON or
YAML.

>
> > 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?
>

Performance is another factor, but the command line limit can be easily
touched when table names have maximum width.

> regards, tom lane
>