aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistxlog.c
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2011-09-01 11:08:32 +0300
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2011-09-01 11:08:32 +0300
commita88b6e4cfbff9802906dd400ef334ffa49e7f286 (patch)
tree00b5c719b8d22950f933dcc77f317de8bde47013 /src/backend/access/gist/gistxlog.c
parent8ea02570677d2cebe681584fd4c22716f1a1e1a7 (diff)
downloadpostgresql-a88b6e4cfbff9802906dd400ef334ffa49e7f286.tar.gz
postgresql-a88b6e4cfbff9802906dd400ef334ffa49e7f286.zip
setlocale() on Windows doesn't work correctly if the locale name contains
dots. I previously worked around this in initdb, mapping the known problematic locale names to aliases that work, but Hiroshi Inoue pointed out that that's not enough because even if you use one of the aliases, like "Chinese_HKG", setlocale(LC_CTYPE, NULL) returns back the long form, ie. "Chinese_Hong Kong S.A.R.". When we try to restore an old locale value by passing that value back to setlocale(), it fails. Note that you are affected by this bug also if you use one of those short-form names manually, so just reverting the hack in initdb won't fix it. To work around that, move the locale name mapping from initdb to a wrapper around setlocale(), so that the mapping is invoked on every setlocale() call. Also, add a few checks for failed setlocale() calls in the backend. These calls shouldn't fail, and if they do there isn't much we can do about it, but at least you'll get a warning. Backpatch to 9.1, where the initdb hack was introduced. The Windows bug affects older versions too if you set locale manually to one of the aliases, but given the lack of complaints from the field, I'm hesitent to backpatch.
Diffstat (limited to 'src/backend/access/gist/gistxlog.c')
0 files changed, 0 insertions, 0 deletions