Over-rigidity in recent to_timestamp() rewrite

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brendan Jurd <direvus(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Over-rigidity in recent to_timestamp() rewrite
Date: 2009-03-14 17:39:35
Message-ID: 6957.1237052375@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Whilst poking at bug #4702 I noticed that PG CVS HEAD rejects use of
AD/BC notation, as well as CC (separate century) fields, in combination
with ISO-style day numbers. I don't see the point of this. It's
historically inaccurate, no doubt, but so is use of Gregorian counting.
So I suggest the attached fix. Does this make anyone unhappy?

regards, tom lane

Index: src/backend/utils/adt/formatting.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/adt/formatting.c,v
retrieving revision 1.155
diff -c -r1.155 formatting.c
*** src/backend/utils/adt/formatting.c 12 Mar 2009 00:53:25 -0000 1.155
--- src/backend/utils/adt/formatting.c 14 Mar 2009 17:37:05 -0000
***************
*** 709,721 ****
*/
static const KeyWord DCH_keywords[] = {
/* name, len, id, is_digit, date_mode */
! {"A.D.", 4, DCH_A_D, FALSE, FROM_CHAR_DATE_GREGORIAN}, /* A */
{"A.M.", 4, DCH_A_M, FALSE, FROM_CHAR_DATE_NONE},
! {"AD", 2, DCH_AD, FALSE, FROM_CHAR_DATE_GREGORIAN},
{"AM", 2, DCH_AM, FALSE, FROM_CHAR_DATE_NONE},
! {"B.C.", 4, DCH_B_C, FALSE, FROM_CHAR_DATE_GREGORIAN}, /* B */
! {"BC", 2, DCH_BC, FALSE, FROM_CHAR_DATE_GREGORIAN},
! {"CC", 2, DCH_CC, TRUE, FROM_CHAR_DATE_GREGORIAN}, /* C */
{"DAY", 3, DCH_DAY, FALSE, FROM_CHAR_DATE_NONE}, /* D */
{"DDD", 3, DCH_DDD, TRUE, FROM_CHAR_DATE_GREGORIAN},
{"DD", 2, DCH_DD, TRUE, FROM_CHAR_DATE_GREGORIAN},
--- 709,721 ----
*/
static const KeyWord DCH_keywords[] = {
/* name, len, id, is_digit, date_mode */
! {"A.D.", 4, DCH_A_D, FALSE, FROM_CHAR_DATE_NONE}, /* A */
{"A.M.", 4, DCH_A_M, FALSE, FROM_CHAR_DATE_NONE},
! {"AD", 2, DCH_AD, FALSE, FROM_CHAR_DATE_NONE},
{"AM", 2, DCH_AM, FALSE, FROM_CHAR_DATE_NONE},
! {"B.C.", 4, DCH_B_C, FALSE, FROM_CHAR_DATE_NONE}, /* B */
! {"BC", 2, DCH_BC, FALSE, FROM_CHAR_DATE_NONE},
! {"CC", 2, DCH_CC, TRUE, FROM_CHAR_DATE_NONE}, /* C */
{"DAY", 3, DCH_DAY, FALSE, FROM_CHAR_DATE_NONE}, /* D */
{"DDD", 3, DCH_DDD, TRUE, FROM_CHAR_DATE_GREGORIAN},
{"DD", 2, DCH_DD, TRUE, FROM_CHAR_DATE_GREGORIAN},
***************
*** 757,769 ****
{"YYY", 3, DCH_YYY, TRUE, FROM_CHAR_DATE_GREGORIAN},
{"YY", 2, DCH_YY, TRUE, FROM_CHAR_DATE_GREGORIAN},
{"Y", 1, DCH_Y, TRUE, FROM_CHAR_DATE_GREGORIAN},
! {"a.d.", 4, DCH_a_d, FALSE, FROM_CHAR_DATE_GREGORIAN}, /* a */
{"a.m.", 4, DCH_a_m, FALSE, FROM_CHAR_DATE_NONE},
! {"ad", 2, DCH_ad, FALSE, FROM_CHAR_DATE_GREGORIAN},
{"am", 2, DCH_am, FALSE, FROM_CHAR_DATE_NONE},
! {"b.c.", 4, DCH_b_c, FALSE, FROM_CHAR_DATE_GREGORIAN}, /* b */
! {"bc", 2, DCH_bc, FALSE, FROM_CHAR_DATE_GREGORIAN},
! {"cc", 2, DCH_CC, TRUE, FROM_CHAR_DATE_GREGORIAN}, /* c */
{"day", 3, DCH_day, FALSE, FROM_CHAR_DATE_NONE}, /* d */
{"ddd", 3, DCH_DDD, TRUE, FROM_CHAR_DATE_GREGORIAN},
{"dd", 2, DCH_DD, TRUE, FROM_CHAR_DATE_GREGORIAN},
--- 757,769 ----
{"YYY", 3, DCH_YYY, TRUE, FROM_CHAR_DATE_GREGORIAN},
{"YY", 2, DCH_YY, TRUE, FROM_CHAR_DATE_GREGORIAN},
{"Y", 1, DCH_Y, TRUE, FROM_CHAR_DATE_GREGORIAN},
! {"a.d.", 4, DCH_a_d, FALSE, FROM_CHAR_DATE_NONE}, /* a */
{"a.m.", 4, DCH_a_m, FALSE, FROM_CHAR_DATE_NONE},
! {"ad", 2, DCH_ad, FALSE, FROM_CHAR_DATE_NONE},
{"am", 2, DCH_am, FALSE, FROM_CHAR_DATE_NONE},
! {"b.c.", 4, DCH_b_c, FALSE, FROM_CHAR_DATE_NONE}, /* b */
! {"bc", 2, DCH_bc, FALSE, FROM_CHAR_DATE_NONE},
! {"cc", 2, DCH_CC, TRUE, FROM_CHAR_DATE_NONE}, /* c */
{"day", 3, DCH_day, FALSE, FROM_CHAR_DATE_NONE}, /* d */
{"ddd", 3, DCH_DDD, TRUE, FROM_CHAR_DATE_GREGORIAN},
{"dd", 2, DCH_DD, TRUE, FROM_CHAR_DATE_GREGORIAN},

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2009-03-14 18:09:39 Re: Over-rigidity in recent to_timestamp() rewrite
Previous Message Tom Lane 2009-03-14 16:25:23 Re: Has anybody think about changing BLCKSZ to an option of initdb?