Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id AC89163353A for ; Tue, 3 Nov 2009 23:36:38 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 64294-02 for ; Wed, 4 Nov 2009 03:36:18 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outA.internet-mail-service.net (outa.internet-mail-service.net [216.240.47.224]) by mail.postgresql.org (Postfix) with ESMTP id 9E02C634036 for ; Tue, 3 Nov 2009 23:36:11 -0400 (AST) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 9C0C4E4AE3; Tue, 3 Nov 2009 19:36:11 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from [192.168.2.105] (adsl-71-135-168-64.dsl.pltn13.pacbell.net [71.135.168.64]) by idiom.com (Postfix) with ESMTP id D3B5C2D6014; Tue, 3 Nov 2009 19:36:09 -0800 (PST) Message-ID: <4AF0F6A7.7070505@obviously.com> Date: Tue, 03 Nov 2009 19:36:07 -0800 From: Bryce Nesbitt User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pgsql-sql@postgresql.org CC: Craig Ringer Subject: Re: Why don't I get a LATIN1 encoding here with SET ENCODING? References: <4AF0D531.5080309@obviously.com> <4AF0E70F.1030201@postnewspapers.com.au> In-Reply-To: <4AF0E70F.1030201@postnewspapers.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.439 tagged_above=-10 required=5 tests=AWL=1.160, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200911/6 X-Sequence-Number: 33357 Craig Ringer wrote: > In truth, that's how I'd expect it to happen. If I ask for the byte 0xfd > in a string, I don't want the server to decide that I must've meant > something else because I have a different client encoding. If I wanted > encoding conversion, I wouldn't have written it in an escape form, I'd > have written 'ý' not '\375'. I've got a client encoding of LATIN1... so I'd expect to be able to present any valid LATIN1 character, not care how the backend stored it, then get the same character back from the database.