From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Re] Re: PREPARE and transactions |
Date: | 2004-07-04 22:21:26 |
Message-ID: | 40E882E6.20008@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeroen T. Vermeulen wrote:
> On Sun, Jul 04, 2004 at 02:33:53PM +1200, Oliver Jowett wrote:
>
>
>>Consider SET client_encoding then..
>
>
> Does that really affect most middleware? In my situation for instance,
> what goes through the connection either way is "just bytes" to the
> middleware. Its interpretation is a client matter. So to me this is a
> client application thing (though of course lower-level than normal SQL)
> and it's also fully transactional.
It certainly affects the JDBC driver -- the native String representation
in Java is UTF-16, so the driver transcodes between that and
client_encoding for parameterized queries and query results involving
strings.
With the V2 protocol, if the application issues a SET client_encoding,
suddenly that transcoding breaks without warning.
With the V3 protocol, at least the driver can notice the change (via a
ParameterStatus message) and complain loudly. It could track the change,
in theory, but since the choice of client_encoding is an implementation
detail for the JDBC driver and everything is going to end up as UTF-16
anyway, there's no real point in allowing it.
So at least from that point of view, client_encoding is very much a
protocol-level thing. Much as I see PREPARE :)
-O
From | Date | Subject | |
---|---|---|---|
Next Message | elein | 2004-07-05 01:07:31 | Bug in PL/Perl CVS head w/spi patch |
Previous Message | Andrew Dunstan | 2004-07-04 22:04:01 | Re: [HACKERS] Compile failure in plperl |