Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 4C27F6332A1 for ; Fri, 24 Apr 2009 05:44:23 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 22559-07 for ; Fri, 24 Apr 2009 05:44:19 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from svr2.hagander.net (svr2.hagander.net [88.198.128.226]) by mail.postgresql.org (Postfix) with ESMTP id CDC2B633064 for ; Fri, 24 Apr 2009 05:44:19 -0300 (ADT) Received: from dynamic.hagander.net ([127.0.0.1]) (encrypted and authenticated) by svr2.hagander.net (Postfix) with ESMTP id 8E34ADCC447; Fri, 24 Apr 2009 10:44:17 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mha-laptop.hagander.net (Postfix) with ESMTP id D7CA0124358; Fri, 24 Apr 2009 10:44:15 +0200 (CEST) Message-ID: <49F17BDF.2060104@hagander.net> Date: Fri, 24 Apr 2009 10:44:15 +0200 From: Magnus Hagander User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Tom Lane CC: Heikki Linnakangas , pgsql-hackers@postgresql.org Subject: Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. References: <20090122100948.89F977559ED@cvs.postgresql.org> <20643.1232666867@sss.pgh.pa.us> <499821F3.7050004@hagander.net> <22474.1234718514@sss.pgh.pa.us> <49D47C40.5040300@hagander.net> <49DC7E11.2050501@enterprisedb.com> <49EC426F.5020602@hagander.net> <5720.1240238282@sss.pgh.pa.us> In-Reply-To: <5720.1240238282@sss.pgh.pa.us> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200904/1252 X-Sequence-Number: 137355 Tom Lane wrote: >> I don't know what it should be doing if it can't find a match, so I >> haven't changed that behavior. > > As things stand, it should throw error, except in the case of SQL_ASCII; > there is no excuse for any other database encoding to not be in the > table. However, what seems more worrisome to me is the prospect already > discussed that the codeset name we have in the table is not actually > recognized by gettext/iconv. Did we have a solution for that? > > Anyway, this fixes my immediate concern about where the info is located, > so you may as well apply it with the array-terminator fix. Done. //Magnus