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
Heikki Linnakangas wrote:
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander mag...@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.
Do you mean a separate table there, or
Magnus Hagander mag...@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
Tom Lane wrote:
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?
You get English.
--
Heikki Linnakangas
EnterpriseDB
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander mag...@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.
Do you mean a separate table there, or should we add a new column
Tom Lane wrote:
Magnus Hagander mag...@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.
Do you mean a separate table there, or should we add a new column to one
of the existing
Tom Lane wrote:
m...@postgresql.org (Magnus Hagander) writes:
Explicitly bind gettext to the correct encoding on Windows.
I have a couple of objections to this patch. First, what happens if
it fails to find a matching table entry? (The existing answer is
nothing, but that doesn't seem
