Neil Conway wrote:
>I would be OK with just ignoring this case, but on reflection I would
>prefer removing the "-t schema.table" syntax. Removing the feature
>resolves the quoting issue and also simplifies pg_dump's behavior. We
>lose the ability to dump table t1 in schema s1 and table t2 in schema s2
>in a single command, but
>
>(a) you can specify "-t t1 -t t2 -n s1 -n s2", although this might also
>dump t1.s2 and/or t2.s1
>
>(b) you can just run pg_dump twice, specifying the appropriate -t and -n
>options each time
>
>So the behavior would be that suggested earlier by David Skoll:
>
>
>
>>pg_dump -t t1 -- Dump table t1 in any schema
>>pg_dump -n s1 -- Dump all of schema s1
>>pg_dump -t t1 -n s1 -- Dump t1 in s1
>>pg_dump -t t1 -t t2 -n s1 -- Dump s1.t1 and s1.t2
>>pg_dump -t t1 -t t2 -n s1 -n s2 -- Dump s1.t1, s1.t2, s2.t1 and s2.t2
>>
>>
>
>We'd only raise an error if we found no matching tables/schemas, as was
>hashed out in July.
>
>
I really prefer the -t "schema.table" syntax over the scenario listed
above. If you look at the syntax for psql "\" commands, and SQL
commands, the structure "tablename, optionally schema-qualified" is seen
time and time again. By allowing the same structure in arguments to
pg_dump, you're helping add to an overall feeling of consistency in the
postgres toolbox.
My feeling is that, to an occasional or novice user of pg_dump, the
proposed combination of -n and -t will seem daunting and idiosyncratic,
especially for complex cases.
The fact that with -n -t there are some cases that are actually
impossible to perform in a single dump is quite a powerful disadvantage
IMO. Yes, you *can* just run pg_dump multiple times, but I think anyone
using pg_dump would rather quote out a wilcard than issue virtually the
same command with one changed argument over and over again. Or writing
a script to loop through the desired schema/table combinations and
dumping each one at a time.
Is command line quoting really that much of a hassle? And if so, what
are the major hurdles?
