Re: Undocumented feature costs a lot of performance in

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Bill Studenmund <wrstuden(at)netbsd(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Undocumented feature costs a lot of performance in
Date: 2001-12-04 18:31:13
Message-ID: 3C0D1671.2030502@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Bill Studenmund wrote:

>>
>>But as long as COPY IN considers that delimiter spec to mean "any one of
>>these characters", and not a multicharacter string, we couldn't do that.
>>
>>If we restrict DELIMITERS strings to be exactly one character for a
>>release or three, we could think about implementing this idea of
>>multicharacter delimiter strings later on. Not sure if anyone really
>>needs it though.
>>
\r\n is quite popular (row) delimiter on some systems (and causes
sometimes a weird box
char to appear at the end of last database field :), but I doubt I can
give any examples
of multichar field delimiters

>> In any case, the current behavior is inconsistent.
>>
>
>I think this restriction sounds fine, and quite practical. :-)
>
I sincerely doubt that anyone knowingly :) uses this undocumented
feature for copy in,
as it can be found out only by trial and error.

Much better to remove it, enforce it in code as Bruce suggested, and
document it.

------------------
Hannu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-12-04 19:00:32 Re: Problem (bug?) with like
Previous Message Doug McNaught 2001-12-04 17:58:47 Re: java stored procedures

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2001-12-04 19:49:05 Undocumented feature costs a lot of performance in COPY IN
Previous Message Bruce Momjian 2001-12-04 17:00:45 Re: hu.po