Re: [HACKERS] Date/time types: big changeu

>   >>> Also, I've changed the default date style to "ISO" (not just in
>   >>> time for Y2K, but we'll be ready for "Y3K").
>   >... Perhaps there should be a way to select the default date
>   >style at configure or initdb time.  I don't mind if the "default default"
>   >is ISO, but if I had apps that were dependent on the old default setting
>   >I'd sure be annoyed by this change...

Well, that is the joy of a major release; not all backward
compatibility is guaranteed. This has been a *documented change* for
at least a year or two; check the chapter on date/time data types for
more info.

However, istm that we could/should have more "default settings"
traveling in the pg_database table. We've got the encoding, which if
set for template1 will be set for every db. We've got the database
location, which can point to an alternate location.

Wouldn't it be reasonable to allow a "default datestyle", or something
more general to help with other defaults? Hmm, could be a text field
which allows something like "PGDATESTYLE='ISO',LANGUAGE='french',..."
so that it is extensible, but maybe that detail is a bad idea because
it is a bit fragile.

What fields would be appropriate for v7.0? The datestyle and timezone
are two obvious candidates, and if we add them now then we could make
use of them later.

Later, we can get things like 
 ALTER DATABASE SET DEFAULT DATESTYLE='ISO';

etc etc.

For v7.1, I'm hoping to work with Tatsuo and others to get closer to
the general character sets and collation sequences allowed by SQL92.
At that point, the MULTIBYTE hardcoded differences in the backend
might go away and we will need these configurable default values.
                   - Thomas

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