Re: proposal: possibility to read dumped table's name from file
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>,
Justin Pryzby <pryzby@telsasoft.com>,
Stephen Frost <sfrost@snowman.net>,
Surafel Temesgen <surafel3000@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
vignesh C <vignesh21@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Daniel Gustafsson <daniel@yesql.se>
Date: 2020-11-25T20:00:32Z
Lists: pgsql-hackers
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? regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix array subscript warnings
- 17935e1fdf0a 17.0 landed
-
Read include/exclude commands for dump/restore from file
- a5cf808be55b 17.0 landed
-
Allow records to span multiple lines in pg_hba.conf and pg_ident.conf.
- 8f8154a503c7 14.0 cited