Re: [HACKERS] Open the flood gates...v6.4 is tag'd...

Thus spake Thomas G. Lockhart
> I deleted one or a few messages from this thread, but at least one
> message which I still have (kept them once I realized this issue was
> blowing up) mentions:

Aw!  And I thought everyone was keeping all my messages just because
of the wonderful prose.

> >> OK, there are more problems.  If you apply the following patch to 
> >> the regression tests you will crash the backend in a number of 
> >> places.
> 
> but there was no patch enclosed or following. 

My copy of the message has the patch by here it is again.


*** ../sql/abstime.sql    Sat May 31 22:30:19 1997
--- abstime.sql    Mon Nov  2 09:17:48 1998
***************
*** 23,28 ****
--- 23,30 ----  INSERT INTO ABSTIME_TBL (f1) VALUES ('May 10, 1947 23:59:12'); 
+ INSERT INTO ABSTIME_TBL (f1) VALUES (null);
+   -- what happens if we specify slightly misformatted abstime?  INSERT INTO ABSTIME_TBL (f1) VALUES ('Feb 35, 1946
10:00:00');
*** ../sql/char.sql    Sun Nov 30 21:46:01 1997
--- char.sql    Mon Nov  2 09:24:51 1998
***************
*** 30,35 ****
--- 30,38 ---- -- zero-length char  INSERT INTO CHAR_TBL (f1) VALUES (''); 
+ -- null input
+ INSERT INTO CHAR_TBL (f1) VALUES (null);
+  -- try char's of greater than 1 length  INSERT INTO CHAR_TBL (f1) VALUES ('cd'); 
*** ../sql/circle.sql    Tue Jul 29 12:22:44 1997
--- circle.sql    Mon Nov  2 09:26:18 1998
***************
*** 16,21 ****
--- 16,23 ----  INSERT INTO CIRCLE_TBL VALUES ('<(100,0),100>'); 
+ INSERT INTO CIRCLE_TBL VALUES (null);
+  -- bad values  INSERT INTO CIRCLE_TBL VALUES ('<(-100,0),-100>');
*** ../sql/datetime.sql    Fri Nov 14 21:55:57 1997
--- datetime.sql    Mon Nov  2 09:30:37 1998
***************
*** 18,23 ****
--- 18,24 ---- INSERT INTO DATETIME_TBL VALUES ('tomorrow'); INSERT INTO DATETIME_TBL VALUES ('tomorrow EST'); INSERT
INTODATETIME_TBL VALUES ('tomorrow zulu');
 
+ INSERT INTO DATETIME_TBL VALUES (null);  SELECT count(*) AS one FROM DATETIME_TBL WHERE d1 = 'today'::datetime;
SELECTcount(*) AS one FROM DATETIME_TBL WHERE d1 = 'tomorrow'::datetime;
 
***************
*** 42,47 ****
--- 43,49 ---- INSERT INTO DATETIME_TBL VALUES ('-infinity'); INSERT INTO DATETIME_TBL VALUES ('infinity'); INSERT INTO
DATETIME_TBLVALUES ('epoch');
 
+ INSERT INTO DATETIME_TBL VALUES (null);  -- Postgres v6.0 standard output format INSERT INTO DATETIME_TBL VALUES
('MonFeb 10 17:32:01 1997 PST');
 
*** ../sql/horology.sql    Sat Sep 20 12:34:07 1997
--- horology.sql    Mon Nov  2 09:34:55 1998
***************
*** 15,20 ****
--- 15,22 ----   WHERE d1 BETWEEN '13-jun-1957' AND '1-jan-1997'    OR d1 BETWEEN '1-jan-1999' AND '1-jan-2010'; 
+ INSERT INTO TEMP_DATETIME (f1) VALUES (null);
+  SELECT '' AS ten, f1 AS datetime   FROM TEMP_DATETIME   ORDER BY datetime;
*** ../sql/inet.sql    Thu Oct 29 13:13:03 1998
--- inet.sql    Mon Nov  2 09:36:06 1998
***************
*** 15,20 ****
--- 15,21 ---- INSERT INTO INET_TBL (c, i) VALUES ('10', '10.1.2.3/8'); INSERT INTO INET_TBL (c, i) VALUES ('10',
'11.1.2.3/8');INSERT INTO INET_TBL (c, i) VALUES ('10', '9.1.2.3/8');
 
+ INSERT INTO INET_TBL (c, i) VALUES (null, null);  SELECT '' AS ten, c AS cidr, i AS inet FROM INET_TBL; 
*** ../sql/lseg.sql    Tue Jul 29 12:22:46 1997
--- lseg.sql    Mon Nov  2 09:36:46 1998
***************
*** 10,15 ****
--- 10,16 ---- INSERT INTO LSEG_TBL VALUES ('10,-10 ,-3,-4'); INSERT INTO LSEG_TBL VALUES ('[-1e6,2e2,3e5, -4e1]');
INSERTINTO LSEG_TBL VALUES ('(11,22,33,44)');
 
+ INSERT INTO LSEG_TBL VALUES (null);  -- bad values for parser testing INSERT INTO LSEG_TBL VALUES ('(3asdf,2
,3,4r2)');
*** ../sql/name.sql    Mon Apr 27 09:50:03 1998
--- name.sql    Mon Nov  2 09:37:57 1998
***************
*** 28,33 ****
--- 28,35 ----  INSERT INTO NAME_TBL(f1) VALUES ('1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ'); 
+ INSERT INTO NAME_TBL(f1) VALUES (null);
+   SELECT '' AS seven, NAME_TBL.*; 
*** ../sql/path.sql    Tue Jun  3 10:23:37 1997
--- path.sql    Mon Nov  2 09:39:36 1998
***************
*** 22,27 ****
--- 22,29 ----  INSERT INTO PATH_TBL VALUES ('(11,12,13,14)'); 
+ INSERT INTO PATH_TBL VALUES (null);
+  -- bad values for parser testing INSERT INTO PATH_TBL VALUES ('[(,2),(3,4)]'); 
*** ../sql/point.sql    Wed Sep 24 13:55:38 1997
--- point.sql    Mon Nov  2 09:40:49 1998
***************
*** 12,17 ****
--- 12,19 ----  INSERT INTO POINT_TBL(f1) VALUES ('(-5.0,-12.0)'); 
+ INSERT INTO POINT_TBL(f1) VALUES (null);
+  -- bad format points  INSERT INTO POINT_TBL(f1) VALUES ('asdfasdf'); 
*** ../sql/polygon.sql    Tue Jul 29 12:22:48 1997
--- polygon.sql    Mon Nov  2 09:41:50 1998
***************
*** 25,30 ****
--- 25,32 ----  INSERT INTO POLYGON_TBL(f1) VALUES ('(0.0,1.0),(0.0,1.0)'); 
+ INSERT INTO POLYGON_TBL(f1) VALUES (null);
+  -- bad polygon input strings  INSERT INTO POLYGON_TBL(f1) VALUES ('0.0'); 
*** ../sql/reltime.sql    Thu May  8 23:26:51 1997
--- reltime.sql    Mon Nov  2 09:43:27 1998
***************
*** 12,17 ****
--- 12,19 ----  INSERT INTO RELTIME_TBL (f1) VALUES ('@ 14 seconds ago'); 
+ INSERT INTO RELTIME_TBL (f1) VALUES (null);
+   -- badly formatted reltimes:    INSERT INTO RELTIME_TBL (f1) VALUES ('badly formatted reltime');
*** ../sql/timespan.sql    Thu May  8 23:26:56 1997
--- timespan.sql    Mon Nov  2 09:46:19 1998
***************
*** 10,15 ****
--- 10,16 ---- INSERT INTO TIMESPAN_TBL (f1) VALUES ('6 years'); INSERT INTO TIMESPAN_TBL (f1) VALUES ('5 months');
INSERTINTO TIMESPAN_TBL (f1) VALUES ('5 months 12 hours');
 
+ INSERT INTO TIMESPAN_TBL (f1) VALUES (null);  -- badly formatted timespan:    INSERT INTO TIMESPAN_TBL (f1) VALUES
('badlyformatted timespan');
 
*** ../sql/tinterval.sql    Sat Sep 20 12:33:24 1997
--- tinterval.sql    Mon Nov  2 09:47:23 1998
***************
*** 15,20 ****
--- 15,22 ---- INSERT INTO TINTERVAL_TBL (f1)    VALUES ('["Feb 15 1990 12:15:03" "current"]'); 
+ INSERT INTO TINTERVAL_TBL (f1) VALUES (null);
+   -- badly formatted tintervals  INSERT INTO TINTERVAL_TBL (f1)


> Anyway, I would suggest that, until we plan out what new behaviors we
> really want in the system that we don't submit a patch which breaks many
> of the data types. That kind of change should, imho, be done offline and
> committed as an integrated solution. If you'd like, I'd be happy to
> trade patches with you as we work out the issues and once we (and anyone
> else with an interest) are happy with the new behavior and have
> regression tests which pass then we should commit to the tree.

Sounds good to me but why not discuss it on hackers?

> As you mentioned, the date and time functions check for null inputs and
> behave pretty well, and an interim solution might include using similar
> techniques on the inet/cidr types.

That's what my patch that I haven't submitted does.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.