Re: date formatting and tab-complete patch
От | Karel Zak |
---|---|
Тема | Re: date formatting and tab-complete patch |
Дата | |
Msg-id | 20020307092226.B6447@zf.jcu.cz обсуждение исходный текст |
Ответ на | Re: date formatting and tab-complete patch (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | 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 по дате отправления:
Предыдущее
От: "Zeugswetter Andreas SB SD"Дата:
Сообщение: Re: Postgresql backend to perform vacuum automatically
Следующее
От: "Zeugswetter Andreas SB SD"Дата:
Сообщение: Re: Storage Location / Tablespaces (try 3)