Luke Lonergan wrote:
>
> >
> > Yep, we would _love_ those improvements.
> >
>
> Coming soon, probably from the guy you've never heard of :-)
LOL
> >
> > I am confused why you are confused. :-)
> >
> > Uh, how do you do the escapes if you don't double the escape character
> > on input so you can distinguish a literal escape from one use to mark
> > special data like a literal delimiter or a null?
>
> Escape processing would proceed as before, but the semantics would change to
> allow the use of different characters as the escape character, in addition
> to the special characters for delimiter and newline. Also, escape
> processing would be "false" as the default, so that the only special
> characters by default would be the newline and delimiter characters.
>
> Also of importance is the specification of newline and delimiter as
> arbitrary double byte or 8-bit characters.
I am still confused how you have reliable, never-break semantics without
special escaping.
How do you distinguis an escape-delimiter used to escape a delimiter in
the data from a literal escape-delimiter in the data being loaded --- it
seems impossible to do.
The idea of allowing a different escape character is interesting,
however, and certainly possible. Right now we allow ESCAPE to be
changed only in CSV mode, but I suppose it is possible to allow it to be
changed in non-CSV mode as well.
Or are you saying there would be no escape at all. If you make '@' the
escape, you can't just say @n is a newline because you need to make '@'
output as '@@' so you can distinguish @-n from a newline.
-- 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