Gregory Stark wrote:
Reading the commit message about the TZ encoding issue I'm curious why this
isn't a more widespread problem. How does gettext now what encoding we want
messages in? How do we prevent things like to_char(now(),'month') from
producing strings in an encoding different from
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Reading the commit message about the TZ encoding issue I'm curious why this
isn't a more widespread problem. How does gettext now what encoding we want
messages in? How do we prevent things like to_char(now(),'month') from
Gregory Stark [EMAIL PROTECTED] writes:
Reading the commit message about the TZ encoding issue I'm curious why this
isn't a more widespread problem. How does gettext now what encoding we want
messages in? How do we prevent things like to_char(now(),'month') from
producing strings in an
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Reading the commit message about the TZ encoding issue I'm curious why this
isn't a more widespread problem. How does gettext now what encoding we want
messages in? How do we prevent things like
Gregory Stark [EMAIL PROTECTED] writes:
So does the _() macro automatically recode it to the current server encoding?
From the gettext manual:
---
gettext not only looks up a translation in a message catalog. It also
converts the translation on the fly to the desired output character
set. This
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
So does the _() macro automatically recode it to the current server encoding?
Well, I'm not sure if it's _(), elog() or what, but it does get recoded.
If I have a different client_encoding and get a NOTICE, then both the
server
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
So does the _() macro automatically recode it to the current server
encoding?
Well, I'm not sure if it's _(), elog() or what, but it does get recoded.
If I have a different client_encoding and get
Alvaro Herrera wrote:
Actually I was thinking about things like formatting.c which take localized
strings and return them as data which can end up in the database. If they're
in the wrong encoding then they'll be invalidly encoded strings in the
database.
Oh, I didn't think of that.
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 11:24 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:59 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:32 -0700, Stephan
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Actually I was thinking about things like formatting.c which take
localized
strings and return them as data which can end up in the database. If
they're
in the wrong encoding then they'll be invalidly encoded strings in the
database.
Oh, I
On Sat, 2007-10-06 at 10:15 -0700, Stephan Szabo wrote:
Yeh, it does, but you're forgetting that my original complaint was that
you couldn't use it in an ANY clause, which 4.2 does not exclude.
Bearing in mind you can use a scalar subquery in lots of places, I
thought it worth reporting.
I've been learning much more than I wanted to know about $SUBJECT
since putting in the src/port/chklocale.c code to try to enforce
that our database encoding matches the system locale settings.
There's an ongoing thread in -patches that's been focused on
getting reasonable behavior from the point
On Sat, 6 Oct 2007, Simon Riggs wrote:
On Sat, 2007-10-06 at 10:15 -0700, Stephan Szabo wrote:
Yeh, it does, but you're forgetting that my original complaint was that
you couldn't use it in an ANY clause, which 4.2 does not exclude.
Bearing in mind you can use a scalar subquery in
Alvaro Herrera [EMAIL PROTECTED] writes:
I tried on both a UTF8 and Latin1 terminal and it works OK in all cases.
The cases that would be interesting involve to_char's locale-specific
format codes (eg Dy) along with LC_TIME settings that are deliberately
incompatible with the database encoding.
Tom Lane [EMAIL PROTECTED] writes:
Since nl_langinfo(CODESET) is supposedly determined only by LC_CTYPE, you
could argue that strftime's results should be in that encoding regardless,
It seems to me we aren't actually using strftime any more in any case. We seem
to be using things like
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Since nl_langinfo(CODESET) is supposedly determined only by LC_CTYPE, you
could argue that strftime's results should be in that encoding regardless,
It seems to me we aren't actually using strftime any more in any
Andrew Dunstan wrote:
Magnus Hagander wrote:
Bingo.
With that, all the ECPG regression tests now pass on MSVC builds.
Andrew - please enable it for the buildfarm :-)
Yes, when I have had a chance to test it. Might be a day or so.
I finally managed to get this working after much
Gregory Stark wrote:
It seems to me we aren't actually using strftime any more in any case. We seem
to be using things like _(Monday) instead. Except in my tests I don't get
any French dates even when the server is started in French mode. I think we
just don't have localizations for those
18 matches
Mail list logo
