Re: [GENERAL] trouble with to_char('L') - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [GENERAL] trouble with to_char('L')
Date
Msg-id 201003121713.o2CHDm828424@momjian.us
Whole thread Raw
In response to Re: [GENERAL] trouble with to_char('L')  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: [GENERAL] trouble with to_char('L')
List pgsql-hackers
Takahiro Itagaki wrote:
> 
> Bruce Momjian <bruce@momjian.us> wrote:
> 
> > OK, I have created a new function, win32_wchar_to_db_encoding(), to
> > share the conversion from wide characters to the database encoding.
> > New patch attached.
> 
> Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify
> db_encoding_strdup() with the function. Like this:
> 
> static char *
> db_encoding_strdup(const char *str)
> {
>     char   *pstr;
>     char   *mstr;
> 
>     /* convert the string to the database encoding */
>     pstr = (char *) pg_do_encoding_conversion(
>                         (unsigned char *) str, strlen(str),
>                         GetPlatformEncoding(), GetDatabaseEncoding());
>     mstr = strdup(pstr);
>     if (pstr != str)
>         pfree(pstr);
> 
>     return mstr;
> }
> 
> I beleive the code is harmless on all platforms and we can use it
> instead of strdup() without any #ifdef WIN32 quotes.

OK, I don't have any Win32 people testing this patch so if we want this
fixed for 9.0 someone is going to have to test my patch to see that it
works.  Can you make the adjustments suggested above to my patch and
test it to see that it works so we can apply it for 9.0?

> BTW, I found we'd better to add "ANSI_X3.4-1968" as an alias for
> PG_SQL_ASCII. My Fedora 12 returns the name when --no-locale is used.

OK.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do


pgsql-hackers by date:

Previous
From: Robert Creager
Date:
Subject: Re: buildfarm logging versus embedded nulls
Next
From: Tom Lane
Date:
Subject: Re: Reposnse from backend when wrong user/database request send