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 thos
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 <[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
"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 _(
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
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 subqu
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 o
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 repo
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
>>>
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
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. Let
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 cli
"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 th
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. T
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
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 en
"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')
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 f
18 matches
Mail list logo
