Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

Re: More message encoding woes


  • From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
  • Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
  • Subject: Re: More message encoding woes
  • Date: Mon, 30 Mar 2009 09:32:08 -0400
  • Message-id: <2233.1238419928@sss.pgh.pa.us> <text/plain>

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> In CVS HEAD, we call bind_textdomain_codeset() in SetDatabaseEncoding() 
> which fixes that, but we only do it on Windows. In earlier versions we 
> called it on all platforms, but only for UTF-8. It seems that we should 
> call bind_textdomain_codeset on all platforms and all encodings. 

Yes, this problem has been recognized for some time.

> However, there seems to be a reason why we only do it for Windows on CVS 
> HEAD: we need a mapping from our encoding ID to the OS codeset name, and 
> the OS codeset names vary.

> How can we make this more robust?

One possibility is to assume that the output of nl_langinfo(CODESET)
will be recognized by bind_textdomain_codeset().  Whether that actually
works can only be determined by experiment.

Another idea is to try the values listed in our encoding_match_list[]
until bind_textdomain_codeset succeeds.  The problem here is that the
GNU documentation is *exceedingly* vague about whether
bind_textdomain_codeset behaves sanely (ie throws a recognizable error)
when given a bad encoding name.  (I guess we could look at the source
code.)

			regards, tom lane



Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group