Thread: COPY encoding

In helping someome on IRC it has become apparent that unless I am 
mistaken "COPY foo from 'filename'" is reading the file according to the 
client encoding.

Is that the expected behaviour? The client might have no influence at 
all on the contents of the file. Offhand, I would have said that a 
server-resident file should be interpreted in the database encoding. Of 
course, the client could change its encoding to influence how the file 
is interpreted, but that seems rather kludgy. Maybe we really need an 
encoding parameter to the COPY command.

At the very least we should document the encoding behaviour.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> In helping someome on IRC it has become apparent that unless I am 
> mistaken "COPY foo from 'filename'" is reading the file according to the 
> client encoding.

> Is that the expected behaviour?

Yes, it is.  Not sure if it's adequately documented.
        regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> In helping someome on IRC it has become apparent that unless I am 
>> mistaken "COPY foo from 'filename'" is reading the file according to the 
>> client encoding.
>>     
>
>   
>> Is that the expected behaviour?
>>     
>
> Yes, it is.  Not sure if it's adequately documented.
>   

Will this cover the case?

diff -c -r1.80 copy.sgml
*** copy.sgml   18 Apr 2007 02:28:22 -0000      1.80
--- copy.sgml   16 Jan 2008 20:44:02 -0000
***************
*** 363,368 ****
--- 363,376 ----     happened well into a large copy operation. You might wish to invoke     <command>VACUUM</command>
torecover the wasted space.    </para>
 
+
+    <para>
+     Input data is interpreted according to the current client encoding,
+     and output data is encoded in the the current client encoding, even
+     if the data does not pass through the client but is read from or
+     written to a file.
+    </para>
+  </refsect1>   <refsect1>


cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Yes, it is.  Not sure if it's adequately documented.

> Will this cover the case?

Text looks OK.  I think it might fit better a bit further up, adjacent
to the para about DateStyle which is a somewhat comparable
consideration.
        regards, tom lane