Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id B6D0C632A6C for ; Mon, 20 Apr 2009 11:38:23 -0300 (ADT) 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 54760-01 for ; Mon, 20 Apr 2009 11:38:02 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 71E4D6326EB for ; Mon, 20 Apr 2009 11:38:10 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n3KEc2Vs005721; Mon, 20 Apr 2009 10:38:02 -0400 (EDT) To: Magnus Hagander cc: Heikki Linnakangas , pgsql-hackers@postgresql.org Subject: Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. In-reply-to: <49EC426F.5020602@hagander.net> 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> Comments: In-reply-to Magnus Hagander message dated "Mon, 20 Apr 2009 11:37:51 +0200" Date: Mon, 20 Apr 2009 10:38:02 -0400 Message-ID: <5720.1240238282@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.158 tagged_above=0 required=5 tests=AWL=0.158 X-Spam-Level: X-Archive-Number: 200904/1038 X-Sequence-Number: 137141 Magnus Hagander writes: > Tom Lane wrote: >>> What makes more sense to me is to add a table to encnames.c that >>> provides the gettext name of every encoding that we support. > Here's a patch that moves the table over to encnames.c, and renames it > to look like the others. I think you forgot to include the NULL terminating entry that the loop seems to be expecting. Also, why isn't the array "const"? > 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. regards, tom lane