Re: Bad dumps... - Mailing list pgsql-admin

From mike g
Subject Re: Bad dumps...
Date
Msg-id 1089429340.10763.10.camel@localhost.localdomain
Whole thread Raw
In response to Re: Bad dumps...  (Stef <svb@ucs.co.za>)
Responses Re: Bad dumps...  (Stef <svb@ucs.co.za>)
List pgsql-admin
That could be a bug.  How are you dumping the data?  pg_dump?  Select
query?  How are you restoring the data?  psql?
On Fri, 2004-07-09 at 09:16, Stef wrote:
> 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
getinto the database in the first place?  Why not get rid of them in your UPDATE statement using the replace statement
inthe 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

pgsql-admin by date:

Previous
From: mike g
Date:
Subject: Re: Perl Modules in PL/Perl functions
Next
From: mike g
Date:
Subject: Re: are there ways for 'idle timeout'?