Thread: large object I/O seeing \\xxx encoding with v3 protocol

Hi,

When using the v3 fe/be protocol, data read and written to large
objects via the loread and lowrite functions seems to be \\xxx
encoded, as per literal escaping or data for the BYTEA type. For
instance, newlines written using lowrite() are later received as
\\012. 

[I am seeing this with my own implementation of the fe/be protocol;I'm not using libpq.]

I find this behaviour to be unfortunate, because it differs from the
v2 protocol behaviour, and because I don't see any reason to encode
the binary data in large objects. Was this change intentional?

Thanks,

-- 
Eric Marsden                          <URL:http://www.laas.fr/~emarsden/>

Eric Marsden <emarsden@laas.fr> writes:
> When using the v3 fe/be protocol, data read and written to large
> objects via the loread and lowrite functions seems to be \\xxx
> encoded, as per literal escaping or data for the BYTEA type. For
> instance, newlines written using lowrite() are later received as
> \\012. 

> [I am seeing this with my own implementation of the fe/be protocol;
>  I'm not using libpq.]

It sounds to me like you have asked for textual rather than binary
results from loread.
        regards, tom lane

>>>>> "tl" == Tom Lane <tgl@sss.pgh.pa.us> writes:
 ecm> When using the v3 fe/be protocol, data read and written to large ecm> objects via the loread and lowrite
functionsseems to be \\xxx ecm> encoded, as per literal escaping or data for the BYTEA type. For ecm> instance,
newlineswritten using lowrite() are later received as ecm> \\012. 
 
 tl> It sounds to me like you have asked for textual rather than binary tl> results from loread.
 you're right; I am sending the type of the argument as 0, so it's text.
 It seems to me that it would be more useful, and more consistent with the way text is handled in the fe/be protocol,
touse the character encoding that was requested by the client (the equivalent of PQsetClientEncoding) instead of this
literal\xxx escaping. Would be a backwards-incompatible change, though.
 
  Thanks,   
-- 
Eric Marsden                          <URL:http://www.laas.fr/~emarsden/>

Eric Marsden <emarsden@laas.fr> writes:
>   It seems to me that it would be more useful, and more consistent
>   with the way text is handled in the fe/be protocol, to use the
>   character encoding that was requested by the client (the equivalent
>   of PQsetClientEncoding) instead of this literal \xxx escaping.

Surely not.  This is bytea data we are talking about --- there is no
reason to suppose that encoding has anything to do with it.  If you
want client_encoding to take a hand, you should be storing data as text
not bytea.
        regards, tom lane