Re: Bad dumps...

Can we go back to the beginning here?! If you are doing updates to remove the \N, why are you allowing them to get into the database in the first place? Why not get rid of them in your UPDATE statement using the replace statement in the first place (or dealing with them in your source application before invoking postgres).

Maybe I'm missing the point here!

Hilary

At 13:03 09/07/2004 +0200, you wrote:

>Hilary Forbes mentioned :
>=> This is very similar to my problem with the ascii code 13s when I dumped and couldn't load the dumped data. What I did was to write a short script replaced the offending characters with an empty string which is different to NULL. The other alternative is to have
>
>This sounds like a possible solution, but
>people actually insert the two characters : '\' and 'N'
>as '\N' into this column, which is not null, but is seen
>as null by the COPY statement during import. I'm
>just not happy about the fact that literal and valid '\N'
>values become null next time I import the database.
>
>At the moment I'm doing this :
>update person set per_id_no = '' where per_id_no like '%\N%';
>
>I can also clean the data for this specific column before insertion,
>but not for all other columns in the database where this could possibly happen.
>
>Can I change pg_dump behaviour to dump nulls as a series of characters
>of my choice (as in the COPY statement) and then pg_restore to interpret this
>correctly when importing?
>
>TIA
>Stefan

Hilary Forbes
The DMR Information and Technology Group (www.dmr.co.uk)
Direct tel 01689 889950 Fax 01689 860330
DMR is a UK registered trade mark of DMR Limited
**********************************************************