Re: internationalizing and etc.. - Mailing list pgsql-hackers

> I send you my last letter again, because I'am not sure if you obtain it
> (you had problem with connection (?)).

Actually yes! I was off the air for a week or so, and didn't remember
that I had a mail to answer. Sorry about that...

> > For normal strings, we can implement NATIONAL CHARACTER and CHARACTER
> > SET features from SQL92 to handle locales and alternative languages.
> > We'll do this by defining new types for each language or locale. For
> > date/time, a clear path is to standardize on ISO-8601 formats (already
> > available as an option) which use numeric fields only. SQL92 offers no
> > suggestions on how to do date/time types with alphabetic fields.
> >
> > I'm going to switch the default date format to ISO-8601 for the next
> > release, which should help. We could also think about
> > internationalizing the date/time support as you suggest, with external
> > language-specific catalogs, but a catalog lookup to do date/time i/o
> > would seem to be very slow, for a catalog within Postgres or for an
> > external flat file.
> 
> Yes, external catalogs is problem (speed, needs glibc..), better resolution is
> probably (cached) system catalogs. If I good underatand you, your idea is
> add langs and locales to pg_type (..example), well. After this si not problem
> make internal catalogs for locales with months, days names...etc. And join
> this locales table (pg_locale?) with pg_type via oid and we can implement
> any translator between langs (for datetime strings).
> 
>  (This is better, because in the glibc's catalogs has features which we
> needn't in PgSQL.)
> 
>  Will feature which allow make possible to set LOCALE type during transaction,
> SET LOCALE/NATIONAL command ?
> 
>  If you have any exactly ideas I can help you with it (if you want).
> I have a little time now and I want spend it with PgSQL :-)

My thought for the *first* implementation of locales and character
sets is to do it all through pg_type, pg_proc, and pg_operator, with a
little help from built-in features in the parser to recognize the
SQL92 conventions for character sets.

For the moment then, we focus on the character set features, not on
how to tie this into the date/time features. For SQL92, you can't
change character sets on the fly, though you can specify that they be
converted on the fly. And the same would hold true of the date/time
types. You can't do a "SET LOCALE" and magically find that both
character types and date/time types change locale too. Or I should say
I haven't seen how to do that yet.

> I complete to_char/to_date, and I testing it now. Where/Who I must send this
> routines for moving to contrib (to You or to other major developer)?

Send it to the "patches" list, or directly to the "hackers" list if it
is under 40kbytes. After we look at the code, we will decide if it
goes into contrib or directly into the backend, and will put it into
the tree.
                     - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California