Обсуждение: COPY x FROM STDIN escape handlers

Just to give a little background, using pgdump in "default" mode creates 
a dump file that includes inline newlines and tabs. The solution is to 
use the -Fc option  but it's a little late for that if all one has is a 
"default" dump file. I was hoping to simply run a conversion on the file 
to create an "escaped" version of the file, but none of the traditional 
escape methods appear to work (ie. \n, \010, 0x10, etc).

The code errors out in CopyReadNewline() but it's the result of a call 
from CopyFrom(). From what I can see, there is no escape handler in the 
CopyFrom function. So, should this be considered an enhancement or is 
there an underlying reason why it isn't there? If it's an enhancement, 
I'll patch it and submit it but I *really* don't want to end up with a 
non-standard version of PostgreSQL!

Thanks in advance!

Marc L.

Marc Lavergne <mlavergne-pub@richlava.com> writes:
> Just to give a little background, using pgdump in "default" mode creates 
> a dump file that includes inline newlines and tabs.

How old a PG release are you using?  COPY has quoted special characters
properly for a long time.
        regards, tom lane

I see the problem now. It was my file parser that was escaping the value 
then passing it to PQescapeString which resulted in \\n instead of \n. 
Guess I was on a wild goose chase. I guess PQescapeString() and 
PQputline() are mutally exclusive ... my bad!

Thanks,

Marc L.

Tom Lane wrote:
> Marc Lavergne <mlavergne-pub@richlava.com> writes:
> 
>>Just to give a little background, using pgdump in "default" mode creates 
>>a dump file that includes inline newlines and tabs.
> 
> 
> How old a PG release are you using?  COPY has quoted special characters
> properly for a long time.
> 
>             regards, tom lane
>