Re: Bad dumps...

Поиск
Список
Период
Сортировка
От mike g
Тема Re: Bad dumps...
Дата
Msg-id 1089429340.10763.10.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: Bad dumps...  (Stef <svb@ucs.co.za>)
Ответы Re: Bad dumps...  (Stef <svb@ucs.co.za>)
Список 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 по дате отправления:

Предыдущее
От: mike g
Дата:
Сообщение: Re: Perl Modules in PL/Perl functions
Следующее
От: mike g
Дата:
Сообщение: Re: are there ways for 'idle timeout'?