Remove YYYYMMDDHH24MISS timestamp support

Greenplum had support for parsing YYYYMMDDHH24MISS timestamps, which
upstream did not.  This is however problematic since it cannot be
parsed unambigously. The following example shows a situation when
the parsing will perform a result which is unlikely to be what the
user was expecting:

  postgres=# set datestyle to 'mdy';
  SET
  postgres=# select '13081205132018'::timestamp;
        timestamp
  ---------------------
   1308-12-05 13:20:18
  (1 row)

The original intent was to aid ETL jobs from Teradata which only
supported this format. This is no longer true according to Teradata
documentation.

This retires the functionality (which was highlighted during the
merge process) aligning the code with upstream, and adds a negative
test for it, the corresponding documentation changes in the release
notes are already done. The existing test for this in qp_misc_jiras
was removed along with a test for a format supported in upstream,
which was already covered by existing suites.
Reviewed-by: NRob Eckhardt <reckhardt@pivotal.io>

src/backend/utils/adt/datetime.c

@@ -2867,7 +2867,6 @@ DecodeNumberField(int len, char *str, int fmask,
 				int *tmask, struct pg_tm * tm, fsec_t *fsec, bool *is2digits)
 {
 	char	   *cp;
-	bool		have_frac = false;
 
 	/*
 	 * Have a decimal point? Then this is a date or something with a seconds
@@ -2881,7 +2880,6 @@ DecodeNumberField(int len, char *str, int fmask,
 		 */
 		double		frac;
 
-		have_frac = true;
 		errno = 0;
 		frac = strtod(cp, NULL);
 		if (errno != 0)
@@ -2896,29 +2894,8 @@ DecodeNumberField(int len, char *str, int fmask,
 		len = strlen(str);
 	}
 	/* No decimal point and no complete date yet? */
-	if ((fmask & DTK_DATE_M) != DTK_DATE_M && !have_frac)
+	else if ((fmask & DTK_DATE_M) != DTK_DATE_M)
 	{
-		/* GPDB_94_MERGE_FIXME: Why does GPDB have this special case for this case? */
-		/* yyyymmddhhmmss? */
-		if ((fmask & DTK_DATE_M) != DTK_DATE_M && 
-			(fmask & DTK_TIME_M) != DTK_TIME_M &&
-			len == 14)
-		{
-            *tmask = DTK_DATE_M | DTK_TIME_M; 
-
-            tm->tm_sec = atoi(str + 12); 
-            *(str + 12) = '\0'; 
-            tm->tm_min = atoi(str + 10); 
-            *(str + 10) = '\0'; 
-            tm->tm_hour = atoi(str + 8); 
-            *(str + 8) = '\0'; 
-            tm->tm_mday = atoi(str + 6); 
-            *(str + 6) = '\0'; 
-            tm->tm_mon = atoi(str + 4); 
-            *(str + 4) = '\0'; 
-            tm->tm_year = atoi(str + 0); 
-            return DTK_DATE; 
-        } 
 		if (len >= 6)
 		{
 			*tmask = DTK_DATE_M;
@@ -2938,28 +2915,6 @@ DecodeNumberField(int len, char *str, int fmask,
 			return DTK_DATE;
 		}
 	}
-	else if ((fmask & DTK_DATE_M) != DTK_DATE_M && 
-			 (fmask & DTK_TIME_M) != DTK_TIME_M)
-	{
-        	/* yyyymmddhhmmss? */ 
-        	if (len == 14) 
-        	{ 
-            		*tmask = DTK_DATE_M | DTK_TIME_M; 
-
-            		tm->tm_sec = atoi(str + 12); 
-            		*(str + 12) = '\0'; 
-            		tm->tm_min = atoi(str + 10); 
-            		*(str + 10) = '\0'; 
-            		tm->tm_hour = atoi(str + 8); 
-            		*(str + 8) = '\0'; 
-            		tm->tm_mday = atoi(str + 6); 
-            		*(str + 6) = '\0'; 
-            		tm->tm_mon = atoi(str + 4); 
-            		*(str + 4) = '\0'; 
-            		tm->tm_year = atoi(str + 0); 
-            		return DTK_DATE; 
-        	} 
-	}
 
 	/* not all time fields are specified? */
 	if ((fmask & DTK_TIME_M) != DTK_TIME_M)

src/test/regress/expected/gp_types.out

@@ -236,6 +236,13 @@ SELECT * FROM dml_timestamp ORDER BY 1;
  2012-03-02 00:00:00
 (2 rows)
 
+-- Greenplum 4.3 and 5 had support for YYYYMMDDHH24MISS, which was removed in
+-- v6 since it cannot be parsed without ambiguity. This test should fail.
+SELECT '13081205132018'::timestamp;
+ERROR:  date/time field value out of range: "13081205132018"
+LINE 1: SELECT '13081205132018'::timestamp;
+               ^
+HINT:  Perhaps you need a different "datestyle" setting.
 --
 -- Timestamp with timezone
 --

src/test/regress/expected/gp_types_optimizer.out

@@ -236,6 +236,13 @@ SELECT * FROM dml_timestamp ORDER BY 1;
  2012-03-02 00:00:00
 (2 rows)
 
+-- Greenplum 4.3 and 5 had support for YYYYMMDDHH24MISS, which was removed in
+-- v6 since it cannot be parsed without ambiguity. This test should fail.
+SELECT '13081205132018'::timestamp;
+ERROR:  date/time field value out of range: "13081205132018"
+LINE 1: SELECT '13081205132018'::timestamp;
+               ^
+HINT:  Perhaps you need a different "datestyle" setting.
 --
 -- Timestamp with timezone
 --

src/test/regress/expected/qp_misc_jiras.out

@@ -1322,20 +1322,6 @@ select * from qp_misc_jiras.tbl_694_1 join qp_misc_jiras.tbl_694_2 on qp_misc_ji
 
 drop table qp_misc_jiras.tbl_694_1;
 drop table qp_misc_jiras.tbl_694_2;
--- Postgres timestamp
-select '20081225 130000'::timestamp;
-      timestamp      
----------------------
- 2008-12-25 13:00:00
-(1 row)
-
--- Teradata timestamp
-select '20081225130000'::timestamp;
-      timestamp      
----------------------
- 2008-12-25 13:00:00
-(1 row)
-
 select * from ( select 'a' as a) x join (select 'a' as b) y on a=b;
  a | b 
 ---+---

src/test/regress/expected/qp_misc_jiras_optimizer.out

@@ -1320,20 +1320,6 @@ select * from qp_misc_jiras.tbl_694_1 join qp_misc_jiras.tbl_694_2 on qp_misc_ji
 
 drop table qp_misc_jiras.tbl_694_1;
 drop table qp_misc_jiras.tbl_694_2;
--- Postgres timestamp
-select '20081225 130000'::timestamp;
-      timestamp      
----------------------
- 2008-12-25 13:00:00
-(1 row)
-
--- Teradata timestamp
-select '20081225130000'::timestamp;
-      timestamp      
----------------------
- 2008-12-25 13:00:00
-(1 row)
-
 select * from ( select 'a' as a) x join (select 'a' as b) y on a=b;
  a | b 
 ---+---

src/test/regress/expected/timestamp.out

@@ -1731,37 +1731,3 @@ select timeofday()::date = current_timestamp::date;
  t
 (1 row)
 
---MPP-5665
-select '20081225130000.123456'::timestamp;
-            timestamp            
----------------------------------
- Thu Dec 25 13:00:00.123456 2008
-(1 row)
-
-select '20081225130000'::timestamp;
-        timestamp         
---------------------------
- Thu Dec 25 13:00:00 2008
-(1 row)
-
-select '20081225130000.000000000000000000000'::timestamp;
-        timestamp         
---------------------------
- Thu Dec 25 13:00:00 2008
-(1 row)
-
-select '20090625123002.111111111111'::timestamp;
-            timestamp            
----------------------------------
- Thu Jun 25 12:30:02.111111 2009
-(1 row)
-
--- should error out
-select '2009062512300.111111111111'::timestamp;
-ERROR:  invalid input syntax for type timestamp: "2009062512300.111111111111"
-LINE 1: select '2009062512300.111111111111'::timestamp;
-               ^
-select '200906251230021.111111111111'::timestamp;
-ERROR:  invalid input syntax for type timestamp: "200906251230021.111111111111"
-LINE 1: select '200906251230021.111111111111'::timestamp;
-               ^

src/test/regress/sql/gp_types.sql

@@ -101,6 +101,10 @@ SELECT * FROM dml_timestamp ORDER BY 1;
 UPDATE dml_timestamp SET a = '294277-01-27 AD'::timestamp;
 SELECT * FROM dml_timestamp ORDER BY 1;
 
+-- Greenplum 4.3 and 5 had support for YYYYMMDDHH24MISS, which was removed in
+-- v6 since it cannot be parsed without ambiguity. This test should fail.
+SELECT '13081205132018'::timestamp;
+
 --
 -- Timestamp with timezone
 --

src/test/regress/sql/qp_misc_jiras.sql

@@ -788,10 +788,7 @@ select * from qp_misc_jiras.tbl_694_1 join qp_misc_jiras.tbl_694_2 on qp_misc_ji
 
 drop table qp_misc_jiras.tbl_694_1;
 drop table qp_misc_jiras.tbl_694_2;
--- Postgres timestamp
-select '20081225 130000'::timestamp;
--- Teradata timestamp
-select '20081225130000'::timestamp;
+
 select * from ( select 'a' as a) x join (select 'a' as b) y on a=b;
 select * from ( ( select 'a' as a ) xx join (select 'a' as b) yy on a = b ) x join (select 'a' as c) y on a=c;
 select x.b from ( ( select 'a' as a ) xx join (select 'a' as b) yy on a = b ) x join (select 'a' as c) y on a=c;

src/test/regress/sql/timestamp.sql

@@ -275,12 +275,3 @@ SET DateStyle TO DEFAULT;
 
 -- Make sure timeofdate() and current_time() are doing roughly the same thing
 select timeofday()::date = current_timestamp::date;
-
---MPP-5665
-select '20081225130000.123456'::timestamp;
-select '20081225130000'::timestamp;
-select '20081225130000.000000000000000000000'::timestamp;
-select '20090625123002.111111111111'::timestamp;
--- should error out
-select '2009062512300.111111111111'::timestamp;
-select '200906251230021.111111111111'::timestamp;