RE: Re: newline character handling

From: "Sampath, Krishna" <KSampath(at)ekmail(dot)com>
To: Michael Blakeley <mike(at)blakeley(dot)com>, pgsql-general(at)hub(dot)org
Subject: RE: Re: newline character handling
Date: 2000-04-10 15:48:53
Message-ID: EDD4714513C8D2118B940090273D1A8201183B3C@NJ01SNT11
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


maybe we need a keyword DOS|UNIX or perhaps TEXT|BINARY to tell postgresql
to pick DOS style or UNIX style line endings...

krishna

-----Original Message-----
From: Michael Blakeley [mailto:mike(at)blakeley(dot)com]
Sent: Saturday, April 08, 2000 12:57 PM
To: pgsql-general(at)hub(dot)org
Subject: [GENERAL] Re: newline character handling

> From: "Sampath, Krishna" <KSampath(at)ekmail(dot)com>
> To: pgsql-general(at)postgresql(dot)org
> Subject: newline character handling
> Date: Fri, 7 Apr 2000 15:49:58 -0400
>
> As I tried, using COPY, to import a few flat files created under Windows
> into postgresql running on a Linux machine, I discovered that:
> * If the last field in your record is a string, postgresql imports it,
but
> keeps the ^M as part of the text string.
> * If the last field is numeric, postgresql refuses to import that line
> (because of the ^M, the field is not recognized as a number)
>
> Once I stripped the ^M, the data bulkloaded without a problem. Perhaps
COPY
> should be smarter and recognize the DOS-style line endings?

I'm ok with this for numerics, but against it for text. Why? Because
I work with some binary data, and I wouldn't want the mysterious
problem of not being able to COPY a line containing a record that's
_supposed_ to end in ^M.

-- Mike

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Steve Wolfe 2000-04-10 16:22:49 Re: Re: newline character handling
Previous Message Sampath, Krishna 2000-04-10 15:39:18 RE: BLOB datatype