Re: [HACKERS] Open the flood gates...v6.4 is tag'd...
От | darcy@druid.net (D'Arcy J.M. Cain) |
---|---|
Тема | Re: [HACKERS] Open the flood gates...v6.4 is tag'd... |
Дата | |
Msg-id | m0zbNWK-0000eyC@druid.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Open the flood gates...v6.4 is tag'd... ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: jwieck@debis.com (Jan Wieck)Дата:
Сообщение: Re: [HACKERS] PL/pgSQL a great procedural language for PostgreSQL