Alon Goldshuv wrote:
> Bruce,
>
> The patch is not there to show that something is "broken" is it there to
> show how things could be done in another way, which may or may not be more
> desireable.
Sure, we are always looking for ways to improve things.
> > COPY works as designed. The idea that some guy we have never heard of
> > is going to appear and rewrite COPY's processing and tell us that the
> > existing code is actually broken seems pretty arrogant to me. If it is
> > broken (meaning doesn't work as designed), please show us facts rather
> > than conjecture.
>
> I am sure that the code works as designed. In my previous email I was
> referring to the fact that using COPY with a data field that happens to have
> backslashes in it, and then querying this data field you will get different
> results. For example do COPY of a field "c:\\one\ten\nine" and query for it.
> The result will be much different. This is a problem with clickstream data
> for example. That's all. It's very possible that there are reasons that I
> missed for why things are the way they are.
Yep, you have to double backslahses coming in as data so we can use
backslash for marking null, delimiters, etc. I see no way around that,
and no one since Berkeley has come up with one either. If you have an
idea, we would _love_ to hear it.
> > (Please explain how you handle literal delimiters and nulls with no
> > escape processing.)
> Escape processing is done only for these 2 cases.
OK, how is that done? How about for newlines in the data?
Right now I think that is the only escapes we do. We support more but
basically the only required ones are delimiter and nulls. The others
are around just for convenience.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073