Re: Bad dumps...

From: Stef <svb(at)ucs(dot)co(dot)za>
To: Hilary Forbes <hforbes(at)dmr(dot)co(dot)uk>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Bad dumps...
Date: 2004-07-09 14:16:41
Message-ID: 20040709161641.3e164d8f@svb.ucs.co.za
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Oops, my <Reply all> button doesn't work...

Hilary Forbes mentioned :
=> 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).

Well, my point exactly : why can I have these values physically sitting in
the database, and export successfully, but the import cannot import a
successfully exported database.

I have already found two other text columns where the intention
was to have a value of '\N' (It is an ID code, not the null '\N'), but
the values magically become null when you export and re-import the database.
Also I have no control over the data in these free-hand type text columns.
Users actually decided to put '\N' in there from an application, which I
guess, they should feel free to do, if they want to. But it breaks backups.

Kind Regards
Stefan

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Konstantin Pelepelin 2004-07-09 14:36:08 are there ways for 'idle timeout'?
Previous Message Együd Csaba 2004-07-09 13:17:50 couldn't download postgres