| From: | Magnus Hagander <magnus(at)hagander(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows. |
| Date: | 2009-04-24 08:44:15 |
| Message-ID: | 49F17BDF.2060104@hagander.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2009-04-24 09:43:10 | pgsql: Remove sslverify parameter again, replacing it with two new |
| Previous Message | Magnus Hagander | 2009-04-24 08:43:51 | pgsql: Move gettext encoding names into encnames.c, so we only have one |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-04-24 16:15:40 | Re: GCC 4.4 compiler warnings |
| Previous Message | Zdenek Kotala | 2009-04-24 07:29:30 | Re: cs_CZ vs regression tests, part N+1 |