This patch solves the problem.

At 09:16 PM 2/26/02 +0900, Tatsuo Ishii wrote:
>> When useing COPY FROM 'file' DELIMITER '\254' copyfrom reads past the
>> delimiter and ends up with parse errors when trying to do the insert
>> 
>> 
>> What the ?? why dind' tthat go through with the body of the text.. *sigh*
>> I'll resend in the AM.. 
>
>Good catch. It's definitely a bug in copy command. Please try
>following patches (this is against 7.2).
>
>*** src/backend/commands/copy.c.orig	Tue Feb 26 21:11:05 2002
>--- src/backend/commands/copy.c	Tue Feb 26 21:11:35 2002
>***************
>*** 1024,1030 ****
>  CopyReadAttribute(FILE *fp, bool *isnull, char *delim, int *newline,
char *null_print)
>  {
>  	int			c;
>! 	int			delimc = delim[0];
>  
>  #ifdef MULTIBYTE
>  	int			mblen;
>--- 1024,1030 ----
>  CopyReadAttribute(FILE *fp, bool *isnull, char *delim, int *newline,
char *null_print)
>  {
>  	int			c;
>! 	int			delimc = (unsigned char)delim[0];
>  
>  #ifdef MULTIBYTE
>  	int			mblen;
>
>

Tue, 26 Feb 2002 08:30:01 -0800
Darcy Buskermolen <darcy@ok-connect.com>
Re: COPY FROM is not 8bit clean

Can someone explain why this fixes the problem.  I thought it was safe
to assign a char to an int and do a compare.  The compare I see is:

		if (c == delimc)
			break;


---------------------------------------------------------------------------

Darcy Buskermolen wrote:
> This patch solves the problem.
> 
> At 09:16 PM 2/26/02 +0900, Tatsuo Ishii wrote:
> >> When useing COPY FROM 'file' DELIMITER '\254' copyfrom reads past the
> >> delimiter and ends up with parse errors when trying to do the insert
> >> 
> >> 
> >> What the ?? why dind' tthat go through with the body of the text.. *sigh*
> >> I'll resend in the AM.. 
> >
> >Good catch. It's definitely a bug in copy command. Please try
> >following patches (this is against 7.2).
> >
> >*** src/backend/commands/copy.c.orig	Tue Feb 26 21:11:05 2002
> >--- src/backend/commands/copy.c	Tue Feb 26 21:11:35 2002
> >***************
> >*** 1024,1030 ****
> >  CopyReadAttribute(FILE *fp, bool *isnull, char *delim, int *newline,
> char *null_print)
> >  {
> >  	int			c;
> >! 	int			delimc = delim[0];
> >  
> >  #ifdef MULTIBYTE
> >  	int			mblen;
> >--- 1024,1030 ----
> >  CopyReadAttribute(FILE *fp, bool *isnull, char *delim, int *newline,
> char *null_print)
> >  {
> >  	int			c;
> >! 	int			delimc = (unsigned char)delim[0];
> >  
> >  #ifdef MULTIBYTE
> >  	int			mblen;
> >
> >
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 26 Feb 2002 13:05:37 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: COPY FROM is not 8bit clean
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Can someone explain why this fixes the problem.

Think about a machine where char is signed by default.  Extracting \254
into an int will produce -2, which will not equal \254 returned by getc.

			regards, tom lane

Tue, 26 Feb 2002 18:33:27 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: COPY FROM is not 8bit clean 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Can someone explain why this fixes the problem.
> 
> Think about a machine where char is signed by default.  Extracting \254
> into an int will produce -2, which will not equal \254 returned by getc.

Oh, I thought that the int returned by getc already had that sign
extension, but now I remember it doesn't.  In fact, it specifically
returns an int so -1 can be identified.  Got it.  Seems I am forgetting
some of my C.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 26 Feb 2002 22:09:32 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: COPY FROM is not 8bit clean