Can we go back to the beginning here?! If you are doing updates to remove the \N, why are you allowing them to get
intothe database in the first place? Why not get rid of them in your UPDATE statement using the replace statement in
thefirst 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
didwas to write a short script replaced the offending characters with an empty string which is different to NULL. The
otheralternative 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
**********************************************************
