pg_dump -t option doesn't take schema-qualified table names
It appears that the command "pgsql -t foo.bar" will not dump the table
bar in the schema foo. I saw a patch a while back to add schema support
to pg_dump (with the --namespace option), but I did not see a fix for
this.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
Curt Sampson <cjs@cynic.net> writes:
It appears that the command "pgsql -t foo.bar" will not dump the table
bar in the schema foo. I saw a patch a while back to add schema support
to pg_dump (with the --namespace option), but I did not see a fix for
this.
IMO that's not a bug; you should spell it pg_dump -n foo -t bar.
The other way is ambiguous with a table named "foo.bar".
regards, tom lane
On Tue, 1 Jul 2003, Tom Lane wrote:
Curt Sampson <cjs@cynic.net> writes:
It appears that the command "pgsql -t foo.bar" will not dump the table
bar in the schema foo. I saw a patch a while back to add schema support
to pg_dump (with the --namespace option), but I did not see a fix for
this.IMO that's not a bug; you should spell it pg_dump -n foo -t bar.
The other way is ambiguous with a table named "foo.bar".
Oh, I didn't realize that dots are allowed in table names. But is there
an unambiguous way to specify a specific table in a database if you
don't know your search path? Would that be "foo"."bar" (table bar in
schema foo) as opposed to "foo.bar" (table foo.bar in current schema, if
extant)? If so, then pg_dump -t '"foo"."bar"' would do the right thing,
I'd hope.
If there's no way to unambiguously specify a table name, that rather
worries me....
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
Curt Sampson <cjs@cynic.net> writes:
On Tue, 1 Jul 2003, Tom Lane wrote:
IMO that's not a bug; you should spell it pg_dump -n foo -t bar.
The other way is ambiguous with a table named "foo.bar".
Oh, I didn't realize that dots are allowed in table names. But is there
an unambiguous way to specify a specific table in a database if you
don't know your search path? Would that be "foo"."bar" (table bar in
schema foo) as opposed to "foo.bar" (table foo.bar in current schema, if
extant)? If so, then pg_dump -t '"foo"."bar"' would do the right thing,
I'd hope.
Well, there are both fundamental and practical issues here. The basic
point is that command-line arguments are subject to shell quoting rules
that are quite at variance with SQL rules. We could adopt the rule that
the command argument received by pg_dump is then subject to SQL quoting
rules, but I guarantee you that no one will like the results (we have
actually tried such things in the past...) To take a slightly extreme
example, let's assume I have named my table "I'm an Idiot". You can
actually spell it exactly that way (with the enclosing double quotes)
in SQL ... but what are you going to call it at the shell command level?
The shell will strip the double quotes if you try to spell it the same
way, and then the underlying tool will downcase it if it's following
SQL conventions exactly. (I pass over whether it wouldn't barf on the
embedded spaces.) You won't get far with locutions like
'"I'm an Idiot"', nor other combinations, because the shell and SQL
rules for quotes and escapes are just enough different to be a royal
pain in the arse.
We went around on this a few years ago, and ultimately decided that the
cleanest solution was for pg_dump and related tools to take SQL names
literally as received from the shell --- no dequoting, no downcasing,
but literally (which means re-quoting the names to send in SQL commands,
but I digress). See the archives for the details. That was before
we had any schema support, but I don't think the conclusion would be
different now.
If there's no way to unambiguously specify a table name, that rather
worries me....
"Unambiguous" and "usable" are two different things :-(
regards, tom lane
Hi Tom,
where can i find the -n option in pg_dump. Is there any special version?
I have 7.3.3.
Regards,
Daniel
-----Ursprungliche Nachricht-----
Von: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Gesendet: Dienstag, 1. Juli 2003 15:44
An: Curt Sampson
Cc: pgsql-bugs@postgresql.org
Betreff: Re: [BUGS] pg_dump -t option doesn't take schema-qualified
table names
Curt Sampson <cjs@cynic.net> writes:
It appears that the command "pgsql -t foo.bar" will not dump the table
bar in the schema foo. I saw a patch a while back to add schema support
to pg_dump (with the --namespace option), but I did not see a fix for
this.
IMO that's not a bug; you should spell it pg_dump -n foo -t bar.
The other way is ambiguous with a table named "foo.bar".
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Import Notes
Resolved by subject fallback
Sorry, the -n option will only be available in PostgreSQL 7.4.
---------------------------------------------------------------------------
Wehrle, Daniel wrote:
Hi Tom,
where can i find the -n option in pg_dump. Is there any special version?
I have 7.3.3.Regards,
Daniel
-----Ursprungliche Nachricht-----
Von: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Gesendet: Dienstag, 1. Juli 2003 15:44
An: Curt Sampson
Cc: pgsql-bugs@postgresql.org
Betreff: Re: [BUGS] pg_dump -t option doesn't take schema-qualified
table namesCurt Sampson <cjs@cynic.net> writes:
It appears that the command "pgsql -t foo.bar" will not dump the table
bar in the schema foo. I saw a patch a while back to add schema support
to pg_dump (with the --namespace option), but I did not see a fix for
this.IMO that's not a bug; you should spell it pg_dump -n foo -t bar.
The other way is ambiguous with a table named "foo.bar".regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073