
Morning all...

	Well, v6.4 is branched and in a "released state"...those wanting
to start moving on, go for it.  Those with committer's access to the
source tree, Thomas and I are working up docs for how to access the REL6_4
branch...

	For those wishing to move forward, nothing has changed...except
there is no longer a feature freeze.

	For those submitting patches for REL6_4, please tag your subject
lines [REL6_4]...I will be watching for those in pgsql-patches, but I
don't want to have to determine if its only a 6.4 vs 6.5 related patch...

	If a patch marked [REL6_4] isn't apppllied in a reasonable amount
of time (ie. I disappear pretty much from Friday to Monday), please feel
free to repost it...but as long as that tag is there, I shouldn't miss
anything...

	I will be wrapping up the full release later this evening, after I
eat something...

	Great work everyone...even if the last bit was a little ...
'stressful' :)


Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Wed, 4 Nov 1998 19:50:04 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Open the flood gates...v6.4 is tag'd...
Thus spake The Hermit Hacker
> 	Well, v6.4 is branched and in a "released state"...those wanting
> to start moving on, go for it.  Those with committer's access to the
> source tree, Thomas and I are working up docs for how to access the REL6_4
> branch...

So do I send in my patch or have we decided to fix the null arg problem
in the function dispatcher?

-- 
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.


Wed, 4 Nov 1998 19:46:13 -0500 (EST)
darcy@druid.net
Re: [HACKERS] Open the flood gates...v6.4 is tag'd...
> 	Well, v6.4 is branched and in a "released state"...those wanting
> to start moving on, go for it.

I did a fresh 'cvs checkout' just now to make sure I had a good set
of files, and was dismayed to discover that a whole bunch of dead
subdirectories have reappeared in the CVS tree.  For example,
	pgsql/contrib/ip_and_mac
	pgsql/contrib/multikey
	pgsql/contrib/plpgsql
	pgsql/contrib/sequence
	pgsql/contrib/zap_ltv
which have nothing in them except CVS overhead.

I suppose this is a side effect of marking things "branched" ...
When you have time to spare on prettification, can you make those
directories go away again?

> Those with committer's access to the source tree, Thomas and I are
> working up docs for how to access the REL6_4 branch...

I assume if I just check in without paying attention, I will be
checking into the 6.5-to-be branch?

			regards, tom lane

Wed, 04 Nov 1998 20:14:03 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Open the flood gates...v6.4 is tag'd... 
> > 	Well, v6.4 is branched and in a "released state"...those wanting
> > to start moving on, go for it.
> 
> I did a fresh 'cvs checkout' just now to make sure I had a good set
> of files, and was dismayed to discover that a whole bunch of dead
> subdirectories have reappeared in the CVS tree.  For example,
> 	pgsql/contrib/ip_and_mac
> 	pgsql/contrib/multikey
> 	pgsql/contrib/plpgsql
> 	pgsql/contrib/sequence
> 	pgsql/contrib/zap_ltv
> which have nothing in them except CVS overhead.
> 
> I suppose this is a side effect of marking things "branched" ...
> When you have time to spare on prettification, can you make those
> directories go away again?
> 
> > Those with committer's access to the source tree, Thomas and I are
> > working up docs for how to access the REL6_4 branch...
> 
> I assume if I just check in without paying attention, I will be
> checking into the 6.5-to-be branch?

-P flag gets rid of those.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 4 Nov 1998 20:43:36 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open the flood gates...v6.4 is tag'd...
On Wed, 4 Nov 1998, Tom Lane wrote:

> > 	Well, v6.4 is branched and in a "released state"...those wanting
> > to start moving on, go for it.
> 
> I did a fresh 'cvs checkout' just now to make sure I had a good set
> of files, and was dismayed to discover that a whole bunch of dead
> subdirectories have reappeared in the CVS tree.  For example,
> 	pgsql/contrib/ip_and_mac
> 	pgsql/contrib/multikey
> 	pgsql/contrib/plpgsql
> 	pgsql/contrib/sequence
> 	pgsql/contrib/zap_ltv
> which have nothing in them except CVS overhead.
> 
> I suppose this is a side effect of marking things "branched" ...
> When you have time to spare on prettification, can you make those
> directories go away again?

	Did you use the -P option?  when you checkout, you should do:

	cvs checkout -P pgsql

	It gets rid of the 'dead' directories tha way...

> > Those with committer's access to the source tree, Thomas and I are
> > working up docs for how to access the REL6_4 branch...
> 
> I assume if I just check in without paying attention, I will be
> checking into the 6.5-to-be branch?

	If you didn't check out the v6.4 release explicitly (using -r
REL6_4), you wont' check into it either...

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Wed, 4 Nov 1998 22:35:09 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Open the flood gates...v6.4 is tag'd... 
> So do I send in my patch or have we decided to fix the null arg 
> problem in the function dispatcher?

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:

>> 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. 

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.

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.

                     - Tom

Thu, 05 Nov 1998 06:20:58 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
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@{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.

Thu, 5 Nov 1998 06:24:08 -0500 (EST)
darcy@druid.net (D'Arcy J.M. Cain)
Re: [HACKERS] Open the flood gates...v6.4 is tag'd...
> > but there was no patch enclosed or following.
> My copy of the message has the patch by here it is again.

Oh! I have that patch. I am gathering from the rest of your message that
there are two patches being discussed, but had expected a patch having
to do with source code fixups in that message. Sorry I am befuddled and
confused...

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

Sure.

> > ... an interim solution might include using similar
> > techniques on the inet/cidr types.
> That's what my patch that I haven't submitted does.

OK, sorry, I was confused about which patches do what. How about
submitting your inet/cidr NULL fixup patch for both v6.4.1 and the
development tree? 

Then I would propose that we renew this discussion on general
improvements in a short while (~ 3 weeks?) to give v6.4 time to settle
in and me/us time to recover. Pretty tapped out from the last month of
Postgres. But scrubbing the NULL mechanisms is on my list of interests
for v6.5, so would like us to have a solid couple of months to work on
it, and it sounds like Jan and others will want to contribute.

                      - Tom

Thu, 05 Nov 1998 14:53:40 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Open the flood gates...v6.4 is tag'd...
The Hermit Hacker <scrappy@hub.org> writes:
> On Wed, 4 Nov 1998, Tom Lane wrote:
>> I did a fresh 'cvs checkout' just now to make sure I had a good set
>> of files, and was dismayed to discover that a whole bunch of dead
>> subdirectories have reappeared in the CVS tree.

> 	Did you use the -P option?  when you checkout, you should do:
> 	cvs checkout -P pgsql
> 	It gets rid of the 'dead' directories tha way...

OK, but I hadn't been doing that before ... ah, wait, I see it.
In my ~/.cvsrc file I have
	cvs -z3
	update -d -P
which means that cvs update gets the -P flag automatically.  So my
old tree didn't have the deadwood because I'd run update against it.

Guess I should add "checkout -P" to .cvsrc.

			thanks, tom lane

Thu, 05 Nov 1998 10:13:42 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Open the flood gates...v6.4 is tag'd... 
Thus spake Thomas G. Lockhart
> OK, sorry, I was confused about which patches do what. How about
> submitting your inet/cidr NULL fixup patch for both v6.4.1 and the
> development tree? 

I just submitted it to patches.  I already forget how to submit it
to 6.4.1.

> Then I would propose that we renew this discussion on general
> improvements in a short while (~ 3 weeks?) to give v6.4 time to settle
> in and me/us time to recover. Pretty tapped out from the last month of
> Postgres. But scrubbing the NULL mechanisms is on my list of interests
> for v6.5, so would like us to have a solid couple of months to work on
> it, and it sounds like Jan and others will want to contribute.

OK.  I hope we remember to go and clean out the function handlers though.
No need for the code bloat if they will never have to handle NULLs.
Perhaps they should be asserts after that for a while.

-- 
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.

Fri, 6 Nov 1998 07:09:00 -0500 (EST)
darcy@druid.net (D'Arcy J.M. Cain)
Re: [HACKERS] Open the flood gates...v6.4 is tag'd...