Karel Zak <zakkr@zf.jcu.cz> writes:
> We don't directly call locale stuff in PostgreSQL code. It's
> encapsulated in PGLC_ (pg_locale.c) API and all is cached, for
> this we use localeconv(3) that returns all in one struct.
>
> (What portability of nl_langinfo()? The localeconv() is ANSI C and
> POSIX functions.)
localenconv is posix and ANSI C but it doesn't provide such
functionality (localized month and day names). nl_langinfo conforms to
"The Single UNIX® Specification, Version 2", according to it's manual
page. The portability isn't an issue as long as you provide means to
test and avoid it's use in systems that doesn't provide it. I know
that, at least, Linux and Solaris does, but FreeBSD does not.
[...]
> Sorry didn't see your original patch (I overlook and delete it in my
> IMBOX:-(). But I have a question -- do you solve vice versa
> conversion from string to timestamp? The basic feature of to_char()
> is that all outputs must be possible parse by to_timestamp() with
> same format definition:
No, however the work seems pretty easy.
> test=# select to_char('2001-12-05 00:00:00+01'::timestamp,
> 'fmday dd/month/yyyy');
> to_char
> -----------------------------
> wednesday 05/december /2001
> (1 row)
This example shows another issue. With localized month and day names
the hardcoded paddings doesn't make sense any more since you may have
a month name longer than 9 chars -septiembre- as instance.
If people is interested I may spend some time working with this.
Regards,
Manuel.
