Thread: 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/

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 19073

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.

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

Peter 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