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, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq