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.
03 Dec 2001 13:41:25 -0600
Manuel Sugawara <masm@fciencias.unam.mx>
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.

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, Pennsylvania 19026

Mon, 3 Dec 2001 15:23:42 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: date formatting and tab-complete patch
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.
03 Dec 2001 14:29:11 -0600
Manuel Sugawara <masm@fciencias.unam.mx>
Re: date formatting and tab-complete patch
> > 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, Pennsylvania 19026

Mon, 3 Dec 2001 15:42:38 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: date formatting and tab-complete patch
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.

03 Dec 2001 15:04:36 -0600
Manuel Sugawara <masm@fciencias.unam.mx>
Re: date formatting and tab-complete patch
> 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, Pennsylvania 19026

Mon, 3 Dec 2001 16:17:42 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: date formatting and tab-complete patch
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

Mon, 03 Dec 2001 17:09:23 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: date formatting and tab-complete patch 
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


Tue, 4 Dec 2001 10:18:45 +0800 (PHT)
Manuel Cabido <manny@tinago.msuiit.edu.ph>
Re: date formatting and tab-complete patch
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


Tue, 4 Dec 2001 22:21:31 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: date formatting and tab-complete patch
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.
04 Dec 2001 17:57:11 -0600
Manuel Sugawara <masm@fciencias.unam.mx>
Re: date formatting and tab-complete patch
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'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.)

> > 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 in
 current sources. A correct solution will "per-columns" locales.

 _May be_ all in PostgreSQL is ready (intependent) to LC_TIME, but I
 not 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 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:

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

Wed, 5 Dec 2001 10:20:12 +0100
Karel Zak <zakkr@zf.jcu.cz>
Re: date formatting and tab-complete patch
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.

05 Dec 2001 10:15:37 -0600
Manuel Sugawara <masm@fciencias.unam.mx>
Re: date formatting and tab-complete patch
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 other matter of
 project ... but current to_char(float, '9G999D99') output string 
 that depend on locale. Why don't allow it for 
 to_chat(timenstamp, ...) too? 
 
 But don't forget it must be fast, portable and locale stuff must
 cached and encapsulated in 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

Wed, 5 Dec 2001 17:48:04 +0100
Karel Zak <zakkr@zf.jcu.cz>
Re: date formatting and tab-complete patch
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.

05 Dec 2001 11:33:26 -0600
Manuel Sugawara <masm@fciencias.unam.mx>
Re: date formatting and tab-complete patch
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, but
 if 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 together without
 restriction.

> 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 locales
 for datetime output it must be implemented as _new_ feature. It means
 this new implementation must be backward compatible for all current
 format 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 output
 format. If someone wants use locale depend output must be possible
 set it by some format suffix, for example:

    to_char(now(), 'LCMonth')

 (to_char() already knows work with suffixes, for example FM). And must
 be 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 output
 compatible with current (Oracle) to_char() and is locale independen.

 This solve a problem with "9 Chars", because all non-locales output
 or compilation without locales support will use it like now.

 It's very simular to number formatting by to_char(). There is two 
 patterns for decimal point, 'D' -- for locale depend deciaml point
 and '.' -- 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

Thu, 6 Dec 2001 10:03:22 +0100
Karel Zak <zakkr@zf.jcu.cz>
Re: date formatting and tab-complete patch
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


Thu, 6 Dec 2001 17:39:11 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: date formatting and tab-complete patch
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.
08 Dec 2001 19:41:01 -0600
Manuel Sugawara <masm@fciencias.unam.mx>
Re: date formatting and tab-complete patch
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

Mon, 10 Dec 2001 11:09:04 +0100
Karel Zak <zakkr@zf.jcu.cz>
Re: date formatting and tab-complete patch
Please add this _simple_ patch to actual code. It _fix_ my bug
 in formatting.c.

 Thanks to Manuel Sugawara <masm@fciencias.unam.mx>.

       Karel

         

On Sat, Dec 08, 2001 at 07:41:01PM -0600, Manuel Sugawara wrote:

> 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.
 
-- 
 Karel Zak  <zakkr@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
Mon, 10 Dec 2001 11:18:30 +0100
Karel Zak <zakkr@zf.jcu.cz>
Re: [HACKERS] date formatting and tab-complete patch

Can I get some feedback from someone else before applying this?  Pretty
late in beta.

---------------------------------------------------------------------------

> 
> 
> 
>  Please add this _simple_ patch to actual code. It _fix_ my bug
>  in formatting.c.
> 
>  Thanks to Manuel Sugawara <masm@fciencias.unam.mx>.
> 
>        Karel
> 
>          
> 
> On Sat, Dec 08, 2001 at 07:41:01PM -0600, Manuel Sugawara wrote:
> 
> > 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.
>  
> -- 
>  Karel Zak  <zakkr@zf.jcu.cz>
>  http://home.zf.jcu.cz/~zakkr/
>  
>  C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

-- 
  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

Mon, 10 Dec 2001 06:23:04 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] date formatting and tab-complete patch
On Mon, Dec 10, 2001 at 06:23:04AM -0500, Bruce Momjian wrote:
> 
> Can I get some feedback from someone else before applying this?  Pretty
> late in beta.
> 

 Bruce, see the patch.

 it fix 
    
        "if (type == XXXX || YYYY)" 
 
 to 
 
        "if (type == XXXX || type == YYYY)"

  :-)
 
        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

Mon, 10 Dec 2001 13:14:51 +0100
Karel Zak <zakkr@zf.jcu.cz>
Re: [HACKERS] date formatting and tab-complete patch
Karel Zak <zakkr@zf.jcu.cz> writes:
>  Please add this _simple_ patch to actual code. It _fix_ my bug
>  in formatting.c.

Applied, thanks.

			regards, tom lane

Mon, 10 Dec 2001 10:34:40 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] date formatting and tab-complete patch 
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.

10 Dec 2001 11:01:42 -0600
Manuel Sugawara <masm@fciencias.unam.mx>
Re: date formatting and tab-complete patch
> On Mon, Dec 10, 2001 at 06:23:04AM -0500, Bruce Momjian wrote:
> > 
> > Can I get some feedback from someone else before applying this?  Pretty
> > late in beta.
> > 
> 
>  Bruce, see the patch.
> 
>  it fix 
>     
>         "if (type == XXXX || YYYY)" 
>  
>  to 
>  
>         "if (type == XXXX || type == YYYY)"
> 
>   :-)

I was just being extra cautious because it is so near final and I may
not be around to fix any breakage (in Japan).  Tom applied it.  Thanks
Tom.

-- 
  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

Tue, 11 Dec 2001 05:33:23 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] date formatting and tab-complete patch
On Tue, Dec 11, 2001 at 05:33:23AM -0500, Bruce Momjian wrote:

> I was just being extra cautious because it is so near final and I may

 It's very right that you rabit code-watch-dog. We have like you 
 for this :-))

 I have a great regard for PostgreSQL project management and good
 stability of stable release. I hate something like Linus's: "it is
 possible compile, it must be OK. Well, make release from it". I hate
 non-tested software and shy at regression tests. Products like 2.4.15
 linux kernel is nice exhibition of bad project managment.

> not be around to fix any breakage (in Japan).  Tom applied it.  Thanks
> Tom.

 Yes, thanks.

            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

Tue, 11 Dec 2001 11:57:53 +0100
Karel Zak <zakkr@zf.jcu.cz>
Re: [HACKERS] date formatting and tab-complete patch

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, Pennsylvania 19026

Wed, 6 Mar 2002 23:44:48 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: date formatting and tab-complete patch
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, Pennsylvania 19026

Thu, 7 Mar 2002 00:10:45 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: date formatting and tab-complete patch
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

Thu, 7 Mar 2002 09:22:26 +0100
Karel Zak <zakkr@zf.jcu.cz>
Re: date formatting and tab-complete patch
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.

07 Mar 2002 11:30:47 -0600
Manuel Sugawara <masm@fciencias.unam.mx>
Re: date formatting and tab-complete patch
Bruce Momjian <pgman@candle.pha.pa.us> writes:

> Yes, this was one of the issues.  Can we support both localization
> libraries?

Yes.

Regards,
Manuel.

07 Mar 2002 11:34:28 -0600
Manuel Sugawara <masm@fciencias.unam.mx>
Re: date formatting and tab-complete patch
> > 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)
Thu, 7 Mar 2002 15:48:19 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: date formatting and tab-complete patch