Re: date formatting and tab-complete patch

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
Cc: Manuel Sugawara <masm(at)fciencias(dot)unam(dot)mx>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: date formatting and tab-complete patch
Date: 2002-03-07 04:44:48
Message-ID: 200203070444.g274imm02948@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


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.

Karel Zak wrote:
> On Sat, Dec 08, 2001 at 07:41:01PM -0600, Manuel Sugawara wrote:
> > 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])
>
> 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(at)zf(dot)jcu(dot)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(at)postgresql(dot)org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2002-03-07 04:56:38 Re: Point in time recovery: recreating relation files
Previous Message Neil Conway 2002-03-07 04:26:54 Re: Bad Build

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2002-03-07 05:10:45 Re: date formatting and tab-complete patch
Previous Message Bruce Momjian 2002-03-06 20:49:37 Re: new hash function