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

From Karel Zak
Subject Re: date formatting and tab-complete patch
Date
Msg-id 20020307092226.B6447@zf.jcu.cz
Whole thread Raw
In response to Re: date formatting and tab-complete patch  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Wed, Mar 06, 2002 at 11:44:48PM -0500, Bruce Momjian wrote:
> 
> OK, I have read this thread and am unsure how to proceed.  Is this
> something to apply or does it require more work. The full thread is at:
> 
>     http://candle.pha.pa.us/cgi-bin/pgpatches2
> 
> I will apply the tab completion fix.  That is a separate issue.
It's in my TODO.
       Karel

> Karel Zak wrote:
> > 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 prefix is no
> >  a 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 output
> >  like FM". I mean we needn't support crazy Oracle feature with months 
> >  align for locale version of to_char(). If you will use prefix you 
> >  can be always sure how is input. I think we can keep this Oracle's
> >  feature only for *non-locale version* and for compatibility only.
> >  I have no idea why support month align in new features where we not
> >  limited with some compatibility...
> > 
> >  I still think that 'LC' prefix is good and simply implement-able 
> >  idea that allows mix old features with new features, for example:
> > 
> >  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'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.
> > 
> > > 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
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> > 
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html

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


pgsql-hackers by date:

Previous
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: Postgresql backend to perform vacuum automatically
Next
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: Storage Location / Tablespaces (try 3)