Thread: date formatting and tab-complete patch
Guys, attached is a patch against the 7.2b3 source tree which improves the i18n of the date formatting functions, using the nl_langinfo(3) function, together with an autoconf macro to test it's availability, also an small change to the tab-complete feature of psql which allows to use tables and views interchangeably. Please consider the incorporation of those, small but useful changes, in the upcoming 7.2 release. Kind regards, Manuel.
Attachment
> Guys, attached is a patch against the 7.2b3 source tree which improves > the i18n of the date formatting functions, using the nl_langinfo(3) > function, together with an autoconf macro to test it's availability, > also an small change to the tab-complete feature of psql which allows > to use tables and views interchangeably. Please consider the > incorporation of those, small but useful changes, in the upcoming 7.2 > release. Sorry, too late for 7.2. Added to queue for 7.3: http://216.55.132.35/cgi-bin/pgpatches2 -- 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, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Guys, attached is a patch against the 7.2b3 source tree which improves > > the i18n of the date formatting functions, using the nl_langinfo(3) > > function, together with an autoconf macro to test it's availability, > > also an small change to the tab-complete feature of psql which allows > > to use tables and views interchangeably. Please consider the > > incorporation of those, small but useful changes, in the upcoming 7.2 > > release. > > Sorry, too late for 7.2. Added to queue for 7.3: Oh I see, - maybe for 7.2.1? ;-) - .Any way I miss the pg_config.h.in patch. Attached. Regards, Manuel.
Attachment
> > Sorry, too late for 7.2. Added to queue for 7.3: > > Oh I see, - maybe for 7.2.1? ;-) - .Any way I miss the pg_config.h.in > patch. Attached. OK, got it; now at same location: http://216.55.132.35/cgi-bin/pgpatches2 We don't add features in 7.X.X releases, so it will have to wait for 7.3. Sorry. -- 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, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes: > We don't add features in 7.X.X releases, so it will have to wait for > 7.3. Sorry. That's OK for me, since I already maintain my own version of postgres with "features" that may not be useful for every one, or not acceptable due "backwards compatibility" constrains. However waiting about a year for those small changes to appear in the official release is, IMHO, too much waiting :-(. Regards, Manuel.
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > We don't add features in 7.X.X releases, so it will have to wait for > > 7.3. Sorry. > > That's OK for me, since I already maintain my own version of postgres > with "features" that may not be useful for every one, or not > acceptable due "backwards compatibility" constrains. However waiting > about a year for those small changes to appear in the official > release is, IMHO, too much waiting :-(. Yes, I understand. -- 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, Pennsylvania19026
Manuel Sugawara <masm@fciencias.unam.mx> writes:
> That's OK for me, since I already maintain my own version of postgres
> with "features" that may not be useful for every one, or not
> acceptable due "backwards compatibility" constrains. However waiting
> about a year for those small changes to appear in the official
> release is, IMHO, too much waiting :-(.
The interval between major versions is supposed to be 4 months or so,
not a year. I admit we've had pretty awful luck at keeping to schedule
the past couple of cycles --- but that's not a reason to change the
schedule target, and definitely not a reason to cause the schedule to
slip more by ignoring the feature-freeze rule after beta starts.
regards, tom lane
Hi there, I tried using the binary large object support of Postgresql but it seems to be different from the one supported by Interbase. Is there a way by which I can get rid of the lo_export and lo_import way of doing blob in PostgreSQL? Thanks a lot... manny
Manuel Sugawara writes: > Guys, attached is a patch against the 7.2b3 source tree which improves > the i18n of the date formatting functions, using the nl_langinfo(3) > function, What's the effect of that? > together with an autoconf macro to test it's availability, Please put macros into config/*.m4 (probably c-library.m4). > also an small change to the tab-complete feature of psql which allows > to use tables and views interchangeably. ISTM that in the situation that tab completion covers tables and views are not interchangeable. Do you have an example? -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Manuel Sugawara writes:
>
> > Guys, attached is a patch against the 7.2b3 source tree which improves
> > the i18n of the date formatting functions, using the nl_langinfo(3)
> > function,
>
> What's the effect of that?
Currently none since I miss another part of the patch :-( -attached-,
but if you add:
setlocale(LC_TIME, "");
in src/backend/main/main.c you will see month and day names printed
according to the current locale.
regress=# select to_char(now(),'fmday dd/month/yyyy');
to_char
--------------------------
martes 04/diciembre/2001
(1 row)
> ISTM that in the situation that tab completion covers tables and views are
> not interchangeable. Do you have an example?
select * from <TAB>
\d <TAB>
neither works for views; that's annoying, since most access to many
databases are done through views. Actually the only counterexamples I
found are DROP and ALTER TABLE but, may be, that's enough.
Regards,
Manuel.
Attachment
On Tue, Dec 04, 2001 at 05:57:11PM -0600, Manuel Sugawara wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>
> > Manuel Sugawara writes:
> >
> > > Guys, attached is a patch against the 7.2b3 source tree which improves
> > > the i18n of the date formatting functions, using the nl_langinfo(3)
> > > function,
We don't directly call locale stuff in PostgreSQL code. It'sencapsulated in PGLC_ (pg_locale.c) API and all is cached,
forthis we use localeconv(3) that returns all in one struct.
(What portability of nl_langinfo()? The localeconv() is ANSI C andPOSIX functions.)
> > What's the effect of that?
>
> Currently none since I miss another part of the patch :-( -attached-,
> but if you add:
>
> setlocale(LC_TIME, "");
I mean is here more reason why not use LC_TIME and LC_NUMERIC incurrent sources. A correct solution will "per-columns"
locales.
_May be_ all in PostgreSQL is ready (intependent) to LC_TIME, but Inot sure with it. Thomas?
> in src/backend/main/main.c you will see month and day names printed
> according to the current locale.
>
> regress=# select to_char(now(),'fmday dd/month/yyyy');
> to_char
> --------------------------
> martes 04/diciembre/2001
> (1 row)
Sorry didn't see your original patch (I overlook and delete it in myIMBOX:-(). But I have a question -- do you solve
viceversaconversion from string to timestamp? The basic feature of to_char()is that all outputs must be possible parse
byto_timestamp() withsame format definition:
test=# select to_char('2001-12-05 00:00:00+01'::timestamp, 'fmday dd/month/yyyy');
to_char
-----------------------------wednesday 05/december /2001
(1 row)
test=# select to_timestamp('wednesday 05/december /2001', 'fmday dd/month/yyyy');
to_timestamp
------------------------2001-12-05 00:00:00+01
(1 row)
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
Karel Zak <zakkr@zf.jcu.cz> writes:
> We don't directly call locale stuff in PostgreSQL code. It's
> encapsulated in PGLC_ (pg_locale.c) API and all is cached, for
> this we use localeconv(3) that returns all in one struct.
>
> (What portability of nl_langinfo()? The localeconv() is ANSI C and
> POSIX functions.)
localenconv is posix and ANSI C but it doesn't provide such
functionality (localized month and day names). nl_langinfo conforms to
"The Single UNIX® Specification, Version 2", according to it's manual
page. The portability isn't an issue as long as you provide means to
test and avoid it's use in systems that doesn't provide it. I know
that, at least, Linux and Solaris does, but FreeBSD does not.
[...]
> Sorry didn't see your original patch (I overlook and delete it in my
> IMBOX:-(). But I have a question -- do you solve vice versa
> conversion from string to timestamp? The basic feature of to_char()
> is that all outputs must be possible parse by to_timestamp() with
> same format definition:
No, however the work seems pretty easy.
> test=# select to_char('2001-12-05 00:00:00+01'::timestamp,
> 'fmday dd/month/yyyy');
> to_char
> -----------------------------
> wednesday 05/december /2001
> (1 row)
This example shows another issue. With localized month and day names
the hardcoded paddings doesn't make sense any more since you may have
a month name longer than 9 chars -septiembre- as instance.
If people is interested I may spend some time working with this.
Regards,
Manuel.
On Wed, Dec 05, 2001 at 10:15:37AM -0600, Manuel Sugawara wrote:
> Karel Zak <zakkr@zf.jcu.cz> writes:
>
> > We don't directly call locale stuff in PostgreSQL code. It's
> > encapsulated in PGLC_ (pg_locale.c) API and all is cached, for
> > this we use localeconv(3) that returns all in one struct.
> >
> > (What portability of nl_langinfo()? The localeconv() is ANSI C and
> > POSIX functions.)
>
> localenconv is posix and ANSI C but it doesn't provide such
> functionality (localized month and day names). nl_langinfo conforms to
> "The Single UNIXŽ Specification, Version 2", according to it's manual
> page. The portability isn't an issue as long as you provide means to
> test and avoid it's use in systems that doesn't provide it. I know
> that, at least, Linux and Solaris does, but FreeBSD does not.
But we want FreeBSD and others systems too....
> [...]
> > Sorry didn't see your original patch (I overlook and delete it in my
> > IMBOX:-(). But I have a question -- do you solve vice versa
> > conversion from string to timestamp? The basic feature of to_char()
> > is that all outputs must be possible parse by to_timestamp() with
> > same format definition:
>
> No, however the work seems pretty easy.
>
> > test=# select to_char('2001-12-05 00:00:00+01'::timestamp,
> > 'fmday dd/month/yyyy');
> > to_char
> > -----------------------------
> > wednesday 05/december /2001
> > (1 row)
>
> This example shows another issue. With localized month and day names
> the hardcoded paddings doesn't make sense any more since you may have
> a month name longer than 9 chars -septiembre- as instance.
Magic "9 chars" is nice and popular Oracle feature :-)
> If people is interested I may spend some time working with this.
I already thought about it. You are right it's possible implement,but I mean not is good if some feature anticipate
othermatter ofproject ... but current to_char(float, '9G999D99') output string that depend on locale. Why don't allow
itfor to_chat(timenstamp, ...) too? But don't forget it must be fast, portable and locale stuff mustcached and
encapsulatedin pg_locale.c.The "9 chars" can be used for English locales only.
Comments? 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
Karel Zak <zakkr@zf.jcu.cz> writes: > > This example shows another issue. With localized month and day names > > the hardcoded paddings doesn't make sense any more since you may have > > a month name longer than 9 chars -septiembre- as instance. > > Magic "9 chars" is nice and popular Oracle feature :-) You think so?, May be it was in the teletype or monospaced display times. But now? I don't think so. > The "9 chars" can be used for English locales only. May be add a GUC, something like useless_oracle_compatibility turned on by default (for the backwards compatibility). Believe me, the paddings are mostly useless those days where aplications tends to use more the web or graphical interfaces than terminals or teletypes. Regards, Manuel.
On Wed, Dec 05, 2001 at 11:33:26AM -0600, Manuel Sugawara wrote:
> Karel Zak <zakkr@zf.jcu.cz> writes:
>
> > > This example shows another issue. With localized month and day names
> > > the hardcoded paddings doesn't make sense any more since you may have
> > > a month name longer than 9 chars -septiembre- as instance.
> >
> > Magic "9 chars" is nice and popular Oracle feature :-)
It was irony :-) I don't know why Oracle has this stupid feature, butif we want be compatible, we must use it too....
> You think so?, May be it was in the teletype or monospaced display
> times. But now? I don't think so.
>
> > The "9 chars" can be used for English locales only.
>
> May be add a GUC, something like useless_oracle_compatibility turned
> on by default (for the backwards compatibility). Believe me, the
I not sure with some global switch like 'useless_oracle_compatibility',here must be way how use old and new features
togetherwithoutrestriction.
> paddings are mostly useless those days where aplications tends to use
> more the web or graphical interfaces than terminals or teletypes.
Yesterday I forgot important note: if to_char() will support localesfor datetime output it must be implemented as _new_
feature.It meansthis new implementation must be backward compatible for all currentformat definition. For example:
to_char(now(), 'Month') _must_forever_output_: 'December '
and this output must be independent on locales setting. It's important, because a lot of application depend of current
outputformat.If someone wants use locale depend output must be possibleset it by some format suffix, for example:
to_char(now(), 'LCMonth')
(to_char() already knows work with suffixes, for example FM). And mustbe possible mix it in one format definition:
to_char(now(),'LCMonth Month')
-output-> 'Xxxxxx December '
where 'Xxxxxx' is the Month from locales and 'December ' is outputcompatible with current (Oracle) to_char() and is
localeindependen.
This solve a problem with "9 Chars", because all non-locales outputor compilation without locales support will use it
likenow.
It's very simular to number formatting by to_char(). There is two patterns for decimal point, 'D' -- for locale depend
deciamlpointand '.' -- for "standard" locales independend. With Months/Days it must be same.
Right?
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
Karel Zak writes: > (What portability of nl_langinfo()? The localeconv() is ANSI C and > POSIX functions.) To use the table of contents of the GNU libc manual: * The Lame Way to Locale Data:: ISO C's `localeconv'. * The Elegant and Fast Way:: X/Open's `nl_langinfo'. -- Peter Eisentraut peter_e@gmx.net
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])
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,
so people can still use 'FM' if they want '22/octubre/1974'. Another
issue is that capilalization is also locale depenent, as instance in
spanish we don't capitalize month names, but my crystal ball sees
people complaining because 'Month' doesn't capitalize, so in any case
we need something like a prefix to indicate that we do not want it in
capital letters, nor in small letters, but in the form that the
localization in course prefers, maybe something like 'lmonth'.
Comments?
Regards,
Manuel.
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.
Attachment
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
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.
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@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, Pennsylvania19026
Karel Zak wrote: > On Wed, Dec 05, 2001 at 10:15:37AM -0600, Manuel Sugawara wrote: > > Karel Zak <zakkr@zf.jcu.cz> writes: > > > > > We don't directly call locale stuff in PostgreSQL code. It's > > > encapsulated in PGLC_ (pg_locale.c) API and all is cached, for > > > this we use localeconv(3) that returns all in one struct. > > > > > > (What portability of nl_langinfo()? The localeconv() is ANSI C and > > > POSIX functions.) > > > > localenconv is posix and ANSI C but it doesn't provide such > > functionality (localized month and day names). nl_langinfo conforms to > > "The Single UNIX? Specification, Version 2", according to it's manual > > page. The portability isn't an issue as long as you provide means to > > test and avoid it's use in systems that doesn't provide it. I know > > that, at least, Linux and Solaris does, but FreeBSD does not. > > But we want FreeBSD and others systems too.... Yes, this was one of the issues. Can we support both localization libraries? -- 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, Pennsylvania19026
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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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:
The problem is that we did not reach any agreement :-(. What I would
like, personally, is make the present more locale aware, so we can
reuse code already done with minimal impact (think nls). However Karel
insists that
select to_char(cast('2001/01/01' as timestamp),'fmDDMonYYYY');
should always lead to '1Jan2001' no matter which localization is in
use and I didn't understand the reasons for this. Any way is easy to
implement, however I would like to see agreement on which is the best
way to go.
> I will apply the tab completion fix. That is a separate issue.
When you are there, can you fix the `full' part of the vacuum that
does not complete?
Regards,
Manuel.
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Yes, this was one of the issues. Can we support both localization > libraries? Yes. Regards, Manuel.
> > I will apply the tab completion fix. That is a separate issue. > > When you are there, can you fix the `full' part of the vacuum that > does not complete? Done and applied. Thanks. -- 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 ? psql Index: tab-complete.c =================================================================== RCS file: /cvsroot/pgsql/src/bin/psql/tab-complete.c,v retrieving revision 1.44 diff -c -r1.44 tab-complete.c *** tab-complete.c 7 Mar 2002 04:45:53 -0000 1.44 --- tab-complete.c 7 Mar 2002 20:46:51 -0000 *************** *** 732,741 **** /* VACUUM */ else if (strcasecmp(prev_wd, "VACUUM") == 0) ! COMPLETE_WITH_QUERY("SELECT relname FROM pg_class WHERE relkind='r' and substr(relname,1,%d)='%s' UNION SELECT'ANALYZE'::text"); ! else if (strcasecmp(prev2_wd, "VACUUM") == 0 && strcasecmp(prev_wd, "ANALYZE") == 0) COMPLETE_WITH_QUERY(Query_for_list_of_tables); - /* ... FROM ... */ else if (strcasecmp(prev_wd, "FROM") == 0) --- 732,740 ---- /* VACUUM */ else if (strcasecmp(prev_wd, "VACUUM") == 0) ! COMPLETE_WITH_QUERY("SELECT relname FROM pg_class WHERE relkind='r' and substr(relname,1,%d)='%s' UNION SELECT'FULL'::text UNION SELECT 'ANALYZE'::text"); ! else if (strcasecmp(prev2_wd, "VACUUM") == 0 && (strcasecmp(prev_wd, "FULL") == 0 || strcasecmp(prev_wd, "ANALYZE")== 0)) COMPLETE_WITH_QUERY(Query_for_list_of_tables); /* ... FROM ... */ else if (strcasecmp(prev_wd, "FROM") == 0)