initdb detecting date order
Here's a patch for initdb detecting the date order of the lc_time locale
and initializing the datestyle parameter of the new cluster
accordingly.
This relies on feeding an umambiguous date through strftime("%x") and
checking in which order things come out. (This was suggested to me by
Martin Pitt a while ago.) I've tested this with a number of locales
and it seems to work. Does anyone see a problem with this?
(Documentation and perhaps an initdb progress notification line is of
course still missing.)
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Attachments:
initdb-dateorder.difftext/x-diff; charset=us-ascii; name=initdb-dateorder.diffDownload+62-0
Peter Eisentraut <peter_e@gmx.net> writes:
Here's a patch for initdb detecting the date order of the lc_time locale
and initializing the datestyle parameter of the new cluster
accordingly.
Er, is that really a good idea? It will make it impossible to document
what the "default" behavior is; among other things, this will probably
break installcheck regression tests.
regards, tom lane
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
Here's a patch for initdb detecting the date order of the lc_time locale
and initializing the datestyle parameter of the new cluster
accordingly.Er, is that really a good idea? It will make it impossible to document
what the "default" behavior is; among other things, this will probably
break installcheck regression tests.
FYI, it is a TODO item, with a question mark:
* Have initdb set the input DateStyle (MDY or DMY) based on locale?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Tom Lane wrote:
Er, is that really a good idea? It will make it impossible to
document what the "default" behavior is;
I think a localized default behavior is more important than a fixed
default behavior for everyone. We already adjust the locales and
encodings in initdb and this is just a natural extension of that theme.
No robust application will rely on the default setting anyway; if you
want to be sure you have to set it or at least query it anyway.
among other things, this
will probably break installcheck regression tests.
The regression tests are not affected by this (which may itself be an
issue of concern).
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:
Tom Lane wrote:
Er, is that really a good idea? It will make it impossible to
document what the "default" behavior is;I think a localized default behavior is more important than a fixed
default behavior for everyone. We already adjust the locales and
encodings in initdb and this is just a natural extension of that theme.
No robust application will rely on the default setting anyway; if you
want to be sure you have to set it or at least query it anyway.
Agreed. It seems like a logical extension to what we already do.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Peter Eisentraut <peter_e@gmx.net> writes:
I think a localized default behavior is more important than a fixed
default behavior for everyone. We already adjust the locales and
encodings in initdb and this is just a natural extension of that theme.
So --no-locale would suppress any change? OK, I can live with it.
regards, tom lane