Обсуждение: Open the flood gates...v6.4 is tag'd...
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
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.
> 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_macpgsql/contrib/multikeypgsql/contrib/plpgsqlpgsql/contrib/sequencepgsql/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
> > 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, Pennsylvania19026
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
> 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
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.
> > 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
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 havecvs -z3update -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
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.