Karel Zak <zakkr@zf.jcu.cz> writes:
[...]
> > I was thinking it and I do not like much the idea to add a new
> > prefix. I would like more a new set of functions:
> >
> > * lto_char (date, format [,locale])
> > * lto_date (date,format [,locale])
> > * lto_timestamp (timestamp,format [,locale])
>
> Yes, we can add new function for [,locale], but internaly it
> _must_ be same code as current to_ stuff. I think new prefix is no
> a problem because it's relevant for Months/Days only.
Yes, of course, it _must_ be, almost, the same code. The idea behind a
new set of functions is to have functions with the same functionality
that the currents but that are locale aware, although personally I
would prefer that the present ones were it, you do insist that
> to_char(now(), 'Month') _must_forever_output_: 'December '
With a new set of functions I can use DROP/CREATE to get what I
want. On the other hand, personally I find the filling with spaces
useless, but if somebody in the world is using it, he/she probably
wants to also use it in locale aware code. I do not believe that the
best way to go is to disappear a ``fature'' just because you add a new
one (locale awareness), think about backwards compatibility.
> BTW the [,locale] feature require improve (very careful) pg_locale
> routines because it allows to work with different locales setting
> than use actual DB setting.
>
> If user doesn't set locales directly by [,locale] must be possible
> for 'LC' prefix use actual locales database setting. For example I
> don't want in my applications use harcoded locales setting in queries,
> but I want maintain it by DB setting.
Yeah, That's the idea.
Comments?
Regards,
Manuel.