Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 31DBE9FBE77 for ; Thu, 22 Feb 2007 04:54:22 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 39220-10 for ; Thu, 22 Feb 2007 04:54:15 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from yass.opencloud.co.nz (yass.opencloud.co.nz [131.203.101.226]) by postgresql.org (Postfix) with ESMTP id DDB3D9FBE6C for ; Thu, 22 Feb 2007 04:54:17 -0400 (AST) Received: from [219.89.217.179] (helo=[10.1.1.3]) by yass.opencloud.co.nz with asmtp (TLS-1.0:DHE_RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1HK9iP-0000cJ-P2; Thu, 22 Feb 2007 21:54:14 +1300 Message-ID: <45DD5A29.8020400@opencloud.com> Date: Thu, 22 Feb 2007 21:54:01 +1300 From: Oliver Jowett User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Ken Johanson CC: James Im , pgsql-jdbc@postgresql.org Subject: Re: invalid byte sequence for encoding "UTF8": 0x00 References: <45DAE076.1060407@opencloud.com> <45DD3A3F.5050609@kensystem.com> In-Reply-To: <45DD3A3F.5050609@kensystem.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Broken-Reverse-DNS: no host name found for IP address 219.89.217.179 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=AWL, BAYES_50 X-Spam-Level: X-Archive-Number: 200702/117 X-Sequence-Number: 16673 Ken Johanson wrote: > At least on other servers/drivers I believe nulls are supported (and > should be according to some spec) (The only special-meaning char is > single quote). The driver can't do anything about it, it's a server issue. I can think of some ways the server could support it without extensive changes .. e.g. use a "modified UTF8" representation which stores \u0000 as 0xc0 0x80 internally .. but you'd have to take that up with the backend developers. > I'm wondering how the binary protocol works insofar as handling the NULL > byte; does it precede it with a backslash? The driver sends string parameters out-of-line without escaping (i.e. length field, then raw utf-8 data). The error you see is generated when the server notices that there's a \u0000 there; it rejects the string entirely rather than silently mangling it. -O