Re: date formatting and tab-complete patch

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.