From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | nasr(dot)laili(at)tin(dot)it |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Can you help solve restore problem? |
Date: | 2004-11-23 19:37:57 |
Message-ID: | 29172.1101238677@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ennio-Sr <nasr(dot)laili(at)tin(dot)it> writes:
> This is an extract of the dump file:
> CREATE TABLE "dep_tit" (
> "cod_rif" character(3),
> "titolo" character varying(20),
> "quantity" integer,
> "costo_med_fisc" double precision,
> "data_rif" date,
> "ultima_quot" double precision,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> "data_ult_q" date
> );
> COPY dep_tit (cod_rif, titolo, quantity, costo_med_fisc, data_rif,
> ultima_quot, data_ult_q) FROM stdin;
> 1 Tit. a 100 3.9112 2004-07-23 - -
> 2 Tit. b 100 4.78 2004-07-23 - -
> [...] ^^^^^^ ^^^^^^
It's pretty much impossible to believe that that's what came out of
pg_dump originally, because "-" definitely isn't a possible output value
for either double precision or date. The best theory I can come up with
is that those columns were actually NULL in the source database, and
that something somewhere along the line munged the "\N" null markers into
"-". Does this theory seem to you to hold any water? Has the dump file
been subjected to any indignities like being emailed or copied onto/off
of a Windows machine?
If that is the correct analysis then the easiest fix is probably to edit
the COPY commands to add WITH NULL AS '-' (this assumes that you don't
have any fields where '-' would actually be the value).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Seymour | 2004-11-23 20:05:13 | Re: Upcoming Changes to News Server ... |
Previous Message | Marc G. Fournier | 2004-11-23 19:37:56 | Upcoming Changes to News Server ... |