Re: proposal: possibility to read dumped table's name from file - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: proposal: possibility to read dumped table's name from file |
| Date | |
| Msg-id | CAFj8pRDCr0gvFq8t-s2p9D5Qca8z0B22E9GUiG=0amTtzNHaMA@mail.gmail.com Whole thread Raw |
| In response to | Re: proposal: possibility to read dumped table's name from file (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: proposal: possibility to read dumped table's name from file
(Dean Rasheed <dean.a.rasheed@gmail.com>)
|
| List | pgsql-hackers |
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.)
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
pgsql-hackers by date: