Re: date formatting and tab-complete patch - Mailing list pgsql-hackers

On Sat, Dec 08, 2001 at 07:41:01PM -0600, Manuel Sugawara wrote:
> Karel Zak <zakkr@zf.jcu.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])
Yes, we can add new function for [,locale], but internaly it_must_ be same code as current to_ stuff. I think new
prefixis noa problem because it's relevant for Months/Days only. 
 

> 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,
If you use prefix you can write to docs: "LC prefix truncate outputlike FM". I mean we needn't support crazy Oracle
featurewith months align for locale version of to_char(). If you will use prefix you can be always sure how is input. I
thinkwe can keep this Oracle'sfeature only for *non-locale version* and for compatibility only.I have no idea why
supportmonth align in new features where we notlimited with some compatibility...
 
I still think that 'LC' prefix is good and simply implement-able idea that allows mix old features with new features,
forexample:
 
to_char(now(), '"DE month:" LCMonth "and Oracle month:" Month', de_DE);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'tset locales directly by [,locale] must be possiblefor 'LC' prefix use actual locales database setting. For
exampleIdon't want in my applications use harcoded locales setting in queries,but I want maintain it by DB setting.
 

> 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.
Thanks. I will repost it to paches list.
       Karel

-- Karel Zak  <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz