Re: [PATCHES] initdb detecting date order
Peter Eisentraut <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] initdb detecting date order
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] initdb detecting date order
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/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] initdb detecting date order
Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] initdb detecting date order
Peter Eisentraut <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] 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/
diff -ur ../../../../cvs-pgsql/src/bin/initdb/initdb.c ./initdb.c
--- ../../../../cvs-pgsql/src/bin/initdb/initdb.c 2005-12-03 22:30:51.0 +0100
+++ ./initdb.c 2005-12-09 02:28:41.0 +0100
@@ -57,11 +57,13 @@
#ifdef HAVE_LANGINFO_H
#include
#endif
+#include
#include "libpq/pqsignal.h"
#include "mb/pg_wchar.h"
#include "getaddrinfo.h"
#include "getopt_long.h"
+#include "miscadmin.h"
#ifndef HAVE_INT_OPTRESET
int optreset;
@@ -186,6 +188,7 @@
static void trapsig(int signum);
static void check_ok(void);
static char *escape_quotes(const char *src);
+static int locale_date_order(const char *locale);
static bool chklocale(const char *locale);
static void setlocales(void);
static void usage(const char *progname);
@@ -1195,6 +1198,20 @@
snprintf(repltok, sizeof(repltok), "lc_time = '%s'", lc_time);
conflines = replace_token(conflines, "#lc_time = 'C'", repltok);
+ switch (locale_date_order(lc_time)) {
+ case DATEORDER_YMD:
+ strcpy(repltok, "datestyle = 'iso, ymd'");
+ break;
+ case DATEORDER_DMY:
+ strcpy(repltok, "datestyle = 'iso, dmy'");
+ break;
+ case DATEORDER_MDY:
+ default:
+ strcpy(repltok, "datestyle = 'iso, mdy'");
+ break;
+ }
+ conflines = replace_token(conflines, "#datestyle = 'iso, mdy'", repltok);
+
snprintf(path, sizeof(path), "%s/postgresql.conf", pg_data);
writefile(path, conflines);
@@ -2053,6 +2070,51 @@
}
/*
+ * Determine likely date order from locale
+ */
+static int
+locale_date_order(const char *locale)
+{
+ struct tm testtime;
+ char buf[128];
+ char *posD;
+ char *posM;
+ char *posY;
+ char *save;
+ size_t res;
+
+ save = setlocale(LC_TIME, NULL);
+ if (!save)
+ return DATEORDER_MDY;
+ save = xstrdup(save);
+
+ setlocale(LC_TIME, locale);
+
+ memset(&testtime, 0, sizeof(testtime));
+ testtime.tm_mday = 22;
+ testtime.tm_mon = 10; /* November, should come out as "11" */
+ testtime.tm_year = 133; /* 2033 */
+
+ res = strftime(buf, sizeof(buf), "%x", &testtime);
+
+ setlocale(LC_TIME, save);
+ free(save);
+
+ if (res == 0)
+ return DATEORDER_MDY;
+
+ posM = strstr(buf, "11");
+ posD = strstr(buf, "22");
+ posY = strstr(buf, "33");
+
+ if (posY < posD && posY < posM)
+ return DATEORDER_YMD;
+ if (posD < posM)
+ return DATEORDER_DMY;
+ return DATEORDER_MDY;
+}
+
+/*
* check if given string is a valid locale specifier
*/
static bool
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
