Herouth Maoz wrote:
> It's all in the docs. Why don't you try to copy some of the rows into a
> temporary table, and dump that table using pg_dump -a -t table_name dbname?
> It may give you a clue.
this is unrelated to the slow insert bug, but Herouth's suggestion
reminded me of something that needs to be looked at before 6.5 is out of
beta: pg_dump seems to have problems with mixed case tablenames. There
doesn't seem to be a way to send a quoted tablename into pg_dump as the
value for a -t option, in 6.4.2 (example below). Can someone try this on
6.5beta? I know some issues with quoting output of pg_dump (i.e. COPY)
was addressed, I'm wondering if input parsing got touched.
Actually, groveling through the source, it looks like even 6.4.2 should
"do the right thing": the query is built with the class (table) name
wrapped with fmtId(), which should do exactly this quoting. Anyone else
see this?
P.S. shouldn't the non existence of the table handed to pg_dump raise a
user visible error?
P.P.S. How does one go about setting up a second version of PG to test
on the same machine, without interference with the production (older)
version? I've only got the one machine to test on.
test=> create table TestTable (a int, b text);
CREATE
test=> create table "TestTable" (c int, d text);
CREATE
test=> \q
$ pg_dump -t TestTable test
CREATE TABLE "testtable" ( "a" int4, "b" text);
COPY "testtable" FROM stdin;
\.
$ pg_dump -t "TestTable" test
CREATE TABLE "testtable" ( "a" int4, "b" text);
COPY "testtable" FROM stdin;
\.
$ pg_dump -t \"TestTable\" test
$ pg_dump test
CREATE TABLE "testtable" ( "a" int4, "b" text);
CREATE TABLE "TestTable" ( "c" int4, "d" text);
COPY "testtable" FROM stdin;
\.
COPY "TestTable" FROM stdin;
\.
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
