E - Era name (like, Japanese Imperial) (kind of pointless)
EE - Full era name
Some stuff here:
http://java.sun.com/javase/6/docs/guide/intl/calendar.doc.html
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
> Gavin Sherry wrote:
> > On Wed, 21 Dec 2005, Tom Lane wrote:
> >
> > > Manuel Sugawara writes:
> > > > (Some time ago I proposed an--incomplete--patch and it was rejectd by
> > > > Karel arguing that to_char functions should behave *exactly* the same
> > > > way that they do in Oracle.)
> > >
>
Added to TODO:
* Add missing parameter handling in to_char()
http://archives.postgresql.org/pgsql-hackers/2005-12/msg00948.php
I added a URL in TODO because it is a single message of detail I need to
reference.
--
Patch applied. Thanks.
---
Euler Taveira de Oliveira wrote:
> --- Euler Taveira de Oliveira <[EMAIL PROTECTED]> escreveu:
>
> > I have a patch like this. But this was for 7.4.x. I have to take a
> > look
> > at it.
> >
>
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Eu
--- Euler Taveira de Oliveira <[EMAIL PROTECTED]> escreveu:
> I have a patch like this. But this was for 7.4.x. I have to take a
> look
> at it.
>
The patch is attached. It implements day and month i18n. I fixed a few
misspelling comments. Docs is attached too.
template1=# select to_char(now(), '
--- Karel Zak <[EMAIL PROTECTED]> escreveu:
I have a patch like this. But this was for 7.4.x. I have to take a look
at it.
> That's important point. How resolve this problem Oracle? Maybe we can
> say (in docs) that with non-English locales it works with days/months
> names as in FM (fill) mode.
On Wed, 2005-12-21 at 23:50 -0500, Tom Lane wrote:
> Manuel Sugawara writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> I thought to_char already had i18n behavior. What exactly are you
> >> thinking of changing?
>
> > The modifiers that are suitable to localize. Month and day names comes
> >
Gavin Sherry <[EMAIL PROTECTED]> writes:
> There's some functionality in 10g which PostgreSQL does not have:
Good to know. I'm not an Oracle expert, actually I knew this reading
an article in a past issue of the Oracle's magazine about i18n;
essentially they were talking about how easy was for an
On Wed, 21 Dec 2005, Tom Lane wrote:
> Manuel Sugawara writes:
> > (Some time ago I proposed an--incomplete--patch and it was rejectd by
> > Karel arguing that to_char functions should behave *exactly* the same
> > way that they do in Oracle.)
>
> That is the accepted plan for to_char ... of cour
Tom Lane <[EMAIL PROTECTED]> writes:
> Can we spell the names differently but keep to the same field widths?
> I can see where it might cause problems to change the widths --- other
> than that, no objection.
Quite impossible. But if someone is relaying in the current behavior
of to_char she migh
Manuel Sugawara writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I thought to_char already had i18n behavior. What exactly are you
>> thinking of changing?
> The modifiers that are suitable to localize. Month and day names comes
> to mind and maybe others, I'm not sure what the state of the cod
Qingqing Zhou wrote:
>
> "Manuel Sugawara" wrote
> >
> > i18n == Internationalization (maybe I should say l10n ==
> > localization).
>
> Good hint, I got it :-) Just like a crossword puzzle. 18 means there are 18
> characters between 'i' and 'n' ...
Huh? I don't understand.
--
Bruce Momji
"Manuel Sugawara" wrote
>
> i18n == Internationalization (maybe I should say l10n ==
> localization).
Good hint, I got it :-) Just like a crossword puzzle. 18 means there are 18
characters between 'i' and 'n' ...
Regards,
Qingqing
---(end of broadcast)--
Manuel Sugawara writes:
> (Some time ago I proposed an--incomplete--patch and it was rejectd by
> Karel arguing that to_char functions should behave *exactly* the same
> way that they do in Oracle.)
That is the accepted plan for to_char ... of course, if Oracle changes
to_char every so often, it'
Tom Lane <[EMAIL PROTECTED]> writes:
> I thought to_char already had i18n behavior. What exactly are you
> thinking of changing?
The modifiers that are suitable to localize. Month and day names comes
to mind and maybe others, I'm not sure what the state of the code is,
but I can say that, at lea
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Can you give a small introduction of i18n and what's your plan in
> PostgreSQL?
i18n == Internationalization (maybe I should say l10n ==
localization). This means that to_char functions might lead to
different results depending on the i18n settings. F
Manuel Sugawara writes:
> Now that Oracle supports i18n dependant behavior in its to_char
> formatting functions (at least for its 10g release) I was wondering if
> a patch to support this in PostgreSQL will get accepted.
I thought to_char already had i18n behavior. What exactly are you
thinking
"Manuel Sugawara" wrote
> Now that Oracle supports i18n dependant behavior in its to_char
> formatting functions (at least for its 10g release) I was wondering if
> a patch to support this in PostgreSQL will get accepted. I was hoping
> to work on this now that I have some spare time.
>
Can you
19 matches
Mail list logo
