Re: [HACKERS] Date/time types: big changeu
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Date/time types: big changeu |
Дата | |
Msg-id | 200002180452.XAA04871@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Date/time types: big changeu (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
> > >>> 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. But we have to store this information in the database because it is related to how the data is stored. Do the date/time fields also have that assumption _in_ that stored data? If so, we need it stored in the database, if not, it seems some SET command or psql startup file setting is enough. Many people work on the same database from different locations and may need different settings. I would only store database settings that relate to the data, not how the data is displayed. That stuff belongs outside the database, I think. -- Bruce Momjian | http://www.op.net/~candle 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
В списке pgsql-hackers по дате отправления: