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 INTO DATETIME_TBL VALUES ('tomorrow zulu');
+ INSERT INTO DATETIME_TBL VALUES (null);

SELECT count(*) AS one FROM DATETIME_TBL WHERE d1 = 'today'::datetime;
SELECT count(*) 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_TBL VALUES ('epoch');
+ INSERT INTO DATETIME_TBL VALUES (null);

-- Postgres v6.0 standard output format
INSERT INTO DATETIME_TBL VALUES ('Mon Feb 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]');
INSERT INTO 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');
INSERT INTO TIMESPAN_TBL (f1) VALUES ('5 months 12 hours');
+ INSERT INTO TIMESPAN_TBL (f1) VALUES (null);

-- badly formatted timespan:
INSERT INTO TIMESPAN_TBL (f1) VALUES ('badly formatted 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(at){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.