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
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 |
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 |