Re: date formatting and tab-complete patch

Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> writes:

[...]
> and this output must be independent on locales setting. It's
> important, because a lot of application depend of current output
> format. If someone wants use locale depend output must be possible
> set it by some format suffix, for example:
>
> to_char(now(), 'LCMonth')

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])

Also if we are filling with spaces in the present code we would have
to also do it with the locale aware code. Seems to me that this is a
better way to keep backwards compatibility, so

lto_char('1974/10/22'::date,'dd/month/yyyy','es_MX')

would lead to '22/octubre /1974', filled to 10, since 'septiembre'
which has 10 chars is the longest month name in the 'es' localization,
so people can still use 'FM' if they want '22/octubre/1974'. Another
issue is that capilalization is also locale depenent, as instance in
spanish we don't capitalize month names, but my crystal ball sees
people complaining because 'Month' doesn't capitalize, so in any case
we need something like a prefix to indicate that we do not want it in
capital letters, nor in small letters, but in the form that the
localization in course prefers, maybe something like 'lmonth'.

Comments?

Regards,
Manuel.

PS. By the way, reviewing the code I found a bug that causes the
following test:

to_date(to_char('1979/22/10'::date,'dd/fmrm/yyyy'),'dd/fmrm/yyyy') = '1979/22/10'::date;

give an error instead of a true value. Attached is the patch to fix it
against the 7.2b3 tree.