From: | Bill Studenmund <wrstuden(at)netbsd(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Undocumented feature costs a lot of performance in |
Date: | 2001-12-04 20:31:47 |
Message-ID: | Pine.NEB.4.33.0112041230020.1693-100000@vespasia.home-net.internetconnect.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Tue, 4 Dec 2001, Tom Lane wrote:
> Bill Studenmund <wrstuden(at)netbsd(dot)org> writes:
> > One alternative would be to make the code use different paths for the
> > just-one and many delimiter cases. But then COPY OUT would need fixing.
>
> Well, it's not clear what COPY OUT should *do* with multiple
> alternatives, anyway. Pick one at random? I guess it does that now,
> if you consider "always use the first one" as a random choice. The
I think that'd be fine.
> real problem is that it will only backslash the first one, too. That
Ick. I was thinking that if you gave multiple delimiters, it would escape
each one. Which would be slow, and is why I think seperate code paths
would be good. :-)
> means that data emitted with DELIMITERS "|_=", say, will fail to be
> reloaded correctly if that same DELIMITERS string is given to COPY IN
> --- because any _ or = characters in the data won't be backslashed,
> but would need to be to keep COPY IN from treating them as delimiters.
>
> For COPY OUT's purposes, a sensible interpretation of a multicharacter
> delimiter string would be that the whole string is emitted as the
> delimiter. Eg,
>
> COPY OUT WITH DELIMITERS "<TAB>";
>
> foo<TAB>bar<TAB>baz
> ...
>
> 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. In any case, the current behavior is inconsistent.
I think this restriction sounds fine, and quite practical. :-)
Take care,
Bill
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-12-04 21:18:34 | Re: Undocumented feature costs a lot of performance in COPY |
Previous Message | Bruce Momjian | 2001-12-04 20:26:05 | Release info updated |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-12-04 21:18:34 | Re: Undocumented feature costs a lot of performance in COPY |
Previous Message | Tom Lane | 2001-12-04 20:22:58 | Re: Undocumented feature costs a lot of performance in COPY IN |