Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows.
Date
Msg-id 5720.1240238282@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows.  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows.  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows.  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> 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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Patch for 8.5, transformationHook
Next
From: Tom Lane
Date:
Subject: Re: Patch for 8.5, transformationHook