Обсуждение: 6.6 release
There have been some people who have said they want a 6.6 release with beta to start on February 1. They are Tom Lane, Thomas Lockhart, and myself. Jan and Peter Eisentraut have said they will be ready on that date. Seems foreign key ability would be enough to justify a 6.6. Comments? -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Seems foreign key ability would be enough to justify a 6.6.
Even without foreign keys, we have enough bugfixes in place to justify
a 6.6 release, I think. If Jan can get some amount of foreign key
support working before Feb, that'd be a nice bonus --- but it's not
really necessary.
The way I see it, we should push what we have out the door, and then
settle in for a long slog on 7.0. We need to do WAL, querytree
redesign, long tuples, function manager changeover, date/time type
unification, and probably a couple other things that I don't remember
at this time of night. These are all appropriate for "7.0" because
they are big items and/or will involve some loss of backward
compatibility. Before we start in on that stuff, it'd be good to
consolidate the gains we already have. Almost every day I find myself
saying to someone "that's fixed in current sources". 7.0 is still
a long way away, so we ought to get the existing improvements out
to our users.
(In short, Bruce persuaded me: we ought to do a 6.6 cycle.)
regards, tom lane
Bruce Momjian wrote: > There have been some people who have said they want a 6.6 release with > beta to start on February 1. They are Tom Lane, Thomas Lockhart, and > myself. Jan and Peter Eisentraut have said they will be ready on that > date. > > Seems foreign key ability would be enough to justify a 6.6. > > Comments? >From a user's perspective, that would be great. Our application is composed of over 130 C++ class objects (its about 100K lines of C++) and the move to 6.5 meant: 1) A change throughout the code to lock tables appropriately to support the refint.c code (which itself doesn't work for cascading updates) under MVCC 2) Keep using 6.4 which isn't all that hot for concurrent access, or 3) Wait for referential integrity...and pray the race condition isn't triggered under 6.5 for tables being altered. Due to the nature of our application, and the number of people actually updating and deleting base tables whose keys would require a cascading delete/update, we choose #3...... :-) Mike Mascari
On Fri, 10 Dec 1999, Bruce Momjian wrote:
> There have been some people who have said they want a 6.6 release with
> beta to start on February 1. They are Tom Lane, Thomas Lockhart, and
> myself. Jan and Peter Eisentraut have said they will be ready on that
> date.
>
> Seems foreign key ability would be enough to justify a 6.6.
>
> Comments?
So we'd be looking at Beta on Feb 1st, with a release around Apr 1st, and
beta for 7 being around June 1st, with 7 release for Sept 1st?
IMHO, 7 is waiting for Vadim/WAL...we're doing a 6.6 due to him being
indisposed until Mar/Apr, correct?
Just want to get this clarified, that's all :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Fri, 10 Dec 1999, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Seems foreign key ability would be enough to justify a 6.6.
>
> Even without foreign keys, we have enough bugfixes in place to justify
> a 6.6 release, I think. If Jan can get some amount of foreign key
> support working before Feb, that'd be a nice bonus --- but it's not
> really necessary.
>
> The way I see it, we should push what we have out the door, and then
> settle in for a long slog on 7.0. We need to do WAL, querytree
> redesign, long tuples, function manager changeover, date/time type
> unification, and probably a couple other things that I don't remember
> at this time of night. These are all appropriate for "7.0" because
> they are big items and/or will involve some loss of backward
> compatibility. Before we start in on that stuff, it'd be good to
> consolidate the gains we already have. Almost every day I find myself
> saying to someone "that's fixed in current sources". 7.0 is still
> a long way away, so we ought to get the existing improvements out
> to our users.
Wait, now I'm confused...so between 6.6 and 7, we're talking another year
anyway? *raised eyebrow* Just curious about your 'long slog' above :)
Here's a question...should we beta on Feb 1st but make it 7.0? If we are
going to be looking for a "long slog" for 7, why not "freeze" things on
Feb 1st as v7, and start working on v8 with WAL, long tuples, etc, etc...
Like, what point do we call things a major release? In a sense, MVCC
probably should have been considered a large enough overhaul to warrant
7.0, no?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
>> 7.0 is still a long way away, so we ought to get the existing
>> improvements out to our users.
> Wait, now I'm confused...so between 6.6 and 7, we're talking another year
> anyway? *raised eyebrow* Just curious about your 'long slog' above :)
I hope not a year ... but I could easily believe we have three to six
months of development ahead, if 7.0 is to contain all the stuff I
mentioned.
> Here's a question...should we beta on Feb 1st but make it 7.0? If we are
> going to be looking for a "long slog" for 7, why not "freeze" things on
> Feb 1st as v7, and start working on v8 with WAL, long tuples, etc, etc...
> Like, what point do we call things a major release? In a sense, MVCC
> probably should have been considered a large enough overhaul to warrant
> 7.0, no?
Maybe so. What's in a name, anyway? But I think we've established a
precedent that it takes a really significant jump to bump the front
number. If we didn't call MVCC 7.0, the stuff we currently have
ready-to-go doesn't seem to justify it either. I think what we have
in current sources is a nice maintenance update, or maybe a little more
than that if Jan has a good chunk of foreign-key stuff working. It's
worth getting it out to users --- but it doesn't feel like a "7.0"
to me.
OTOH, we've already changed the version ID in current sources, and
changing it back might not be worth the trouble of arguing ;-)
regards, tom lane
The Hermit Hacker wrote: > > Wait, now I'm confused...so between 6.6 and 7, we're talking another year > anyway? *raised eyebrow* Just curious about your 'long slog' above :) > > Here's a question...should we beta on Feb 1st but make it 7.0? If we are > going to be looking for a "long slog" for 7, why not "freeze" things on > Feb 1st as v7, and start working on v8 with WAL, long tuples, etc, etc... > > Like, what point do we call things a major release? In a sense, MVCC > probably should have been considered a large enough overhaul to warrant > 7.0, no? So, may be call next after 6.6 release just 6.7 ? -:) Does it so matter - v7, v8? I would be happy with 6.7 -:) Vadim
On Fri, 10 Dec 1999, The Hermit Hacker wrote: > Here's a question...should we beta on Feb 1st but make it 7.0? If we are > going to be looking for a "long slog" for 7, why not "freeze" things on > Feb 1st as v7, and start working on v8 with WAL, long tuples, etc, etc... > > Like, what point do we call things a major release? In a sense, MVCC > probably should have been considered a large enough overhaul to warrant > 7.0, no? I thought Marc decided[1] last year to drop the minor.minor version numbers. IOW, there would be no 6.6.1, 6.6.2, etc. Make the upcoming release 7.0 and take care of any minor glitches in it as 7.1, 7.2 and when WAL and the other stuff is ready - or as it's ready - release 8.0 and fix any glitches as 8.1, etc. Currently every minor release is really a major one, so why not just mark it as such and not worry about it? Vince. [1] Or did you do that on inn-workers and not here? It was about the same time FreeBSD dropped the major.minor.minor for the major.minor numbering. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h> Have you seenhttp://www.pop4.net? Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Fri, 10 Dec 1999, Tom Lane wrote:
> Maybe so. What's in a name, anyway? But I think we've established a
> precedent that it takes a really significant jump to bump the front
Actually, we've never set a precedent...v6.0 was so named more because
v1.10 just sounded like such a small number compared to the overall age of
the software...
> OTOH, we've already changed the version ID in current sources, and
> changing it back might not be worth the trouble of arguing ;-)
Okay, I can agree with that one :)
Peter brought up a good argument over on his side too...make the Feb1st
one 7, and we'll make the post-WAL stuff 8.0 ...
Just as a note, I'm not 100% certain how this generally works in "real
life", but, in some circumstances, I've seen it happen where the major
gets bumped a significant number of changes have gone into everything
since the last major bump...I think we have achieved that at least one
release back...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Seems foreign key ability would be enough to justify a 6.6.
>
> Even without foreign keys, we have enough bugfixes in place to justify
> a 6.6 release, I think. If Jan can get some amount of foreign key
> support working before Feb, that'd be a nice bonus --- but it's not
> really necessary.
As far as I see it now, I can get the FK stuff with MATCH
FULL ready by February first. Must be enough.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
On Fri, 10 Dec 1999, Vince Vielhaber wrote:
> On Fri, 10 Dec 1999, The Hermit Hacker wrote:
>
> > Here's a question...should we beta on Feb 1st but make it 7.0? If we are
> > going to be looking for a "long slog" for 7, why not "freeze" things on
> > Feb 1st as v7, and start working on v8 with WAL, long tuples, etc, etc...
> >
> > Like, what point do we call things a major release? In a sense, MVCC
> > probably should have been considered a large enough overhaul to warrant
> > 7.0, no?
>
> I thought Marc decided[1] last year to drop the minor.minor version
> numbers. IOW, there would be no 6.6.1, 6.6.2, etc. Make the upcoming
> release 7.0 and take care of any minor glitches in it as 7.1, 7.2 and
> when WAL and the other stuff is ready - or as it's ready - release 8.0
> and fix any glitches as 8.1, etc. Currently every minor release is really
> a major one, so why not just mark it as such and not worry about it?
>
> Vince.
>
> [1] Or did you do that on inn-workers and not here? It was about the same
> time FreeBSD dropped the major.minor.minor for the major.minor numbering.
Would have been here...
The problem, as I see it, is that the FreeBSD camp is more "strict" in how
it does their source tree...there is a development tree (X.y), and a
stable tree (X-1.y)...if something is back-patchable to X-1.y from X.y, it
gets done (ie. bug fixes, security fixes or even feature changes *as long
as* they don't change the API...
We're about 50% there, but not completely...this last release (6.5) has
been fantastic...ppl have been back-patching to the 6.5 tree, providing us
wiht interim releases, but not to the level that we can build a 6.6 off
that tree...
when we do up Release 7, which I'd like to make this one, I'd *love* to
make this a whole-hog thing...tag/branch things as REL_7, no minor
number...then its up to the developers to decide whether something is
back-patchable (like they've been doing up until now) with a periodic
release put out while Release 8 is being worked on.
It slows down the rush of getting a full release out while allowign ppl
access to the debug'd advances in the upcoming release...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Thus spake Jan Wieck
> As far as I see it now, I can get the FK stuff with MATCH
> FULL ready by February first. Must be enough.
Any chance of getting the FK semantics into the parser right away even
though it is ignored? As soon as it is there we can start modifying
our CREATE TABLE scripts in preparation for when the underlying code
is there.
Hmm. Sounds like an argument I had with Jolly once over PKs. :-)
--
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 425 1212 (DoD#0082) (eNTP) | what's for dinner.
wieck@debis.com (Jan Wieck) writes:
>>>> Seems foreign key ability would be enough to justify a 6.6.
>>
>> Even without foreign keys, we have enough bugfixes in place to justify
>> a 6.6 release, I think.
> As far as I see it now, I can get the FK stuff with MATCH
> FULL ready by February first. Must be enough.
If we need another feature to "justify" a release, I think I just
figured out how to do "COUNT(DISTINCT x)" with only maybe a day's work.
Watch this space...
regards, tom lane
The Hermit Hacker <scrappy@hub.org> writes:
> On Fri, 10 Dec 1999, Vince Vielhaber wrote:
>> I thought Marc decided[1] last year to drop the minor.minor version
>> numbers. IOW, there would be no 6.6.1, 6.6.2, etc. Make the upcoming
>> release 7.0 and take care of any minor glitches in it as 7.1, 7.2 and
>> when WAL and the other stuff is ready - or as it's ready - release 8.0
>> and fix any glitches as 8.1, etc. Currently every minor release is really
>> a major one, so why not just mark it as such and not worry about it?
> when we do up Release 7, which I'd like to make this one, I'd *love* to
> make this a whole-hog thing...tag/branch things as REL_7, no minor
> number...
Yeah, I was thinking that if we were to call this 7.0 and have plans
for going to 8.0 as soon as WAL &etc are done, then we'd basically be
dropping one level of version number --- no need for a third number
if major revs are that close together. That's OK with me as long as
we all understand that it's a change in naming practices. There are
things we'd need to change to make it work. For example, PG_VERSION
would need to record only the top version number: 7.0 and 7.1 would be
expected to have compatible databases, not incompatible ones.
regards, tom lane
Marc G. Fournier wrote:
> when we do up Release 7, which I'd like to make this one, I'd *love* to
> make this a whole-hog thing...tag/branch things as REL_7, no minor
> number...then its up to the developers to decide whether something is
> back-patchable (like they've been doing up until now) with a periodic
> release put out while Release 8 is being worked on.
I would really appreceate that. Maybe we need to go ahead in
this manner and make more use of CVS branching.
We have long standing TODO items, which require co work of
multiple developers, affect alot of the code and will take a
long time to implement. Tuple split, fmgr redesign, parsetree
overhaul to name some.
Especially the fact that noone can do them alone IMHO
requires to have a separate branch, where the sources can
stay broken for some time. For example if we change the
parsetree representation, we first change the parser and look
at the printed output's until it fits. Then work on the
planner to get them running and parallel enhance the rewriter
to integrate it again. During this time, the parser will
generate things that may make the entire system unusable, so
any other development would get stuck.
I don't think that all problems could be tackled at once. My
idea is to analyze one of these problems in depth, then
branch off and have the developers, required to get this item
done, doing it separated there. The final result will be a
patch based on an older release, that requires some manual
work to get it merged into the current tree, of course. The
benefit would be, that this long term development would not
be interfered by CURRENT improvements, nor will it delay any
subsequent releasing of funny, neat things.
Just an idea.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
>
> Thus spake Jan Wieck
> > As far as I see it now, I can get the FK stuff with MATCH
> > FULL ready by February first. Must be enough.
>
> Any chance of getting the FK semantics into the parser right away even
> though it is ignored? As soon as it is there we can start modifying
> our CREATE TABLE scripts in preparation for when the underlying code
> is there.
>
> Hmm. Sounds like an argument I had with Jolly once over PKs. :-)
The current source tree only lacks the parsers part to
specify
INITIALLY DEFERRED|IMMEDIATE
[ NOT ] DEFERRABLE
in a columns REFERENCES clause. They are fully supported in a
tables CONSTRAINT clause.
All the functionality for MATCH FULL is there too already.
Though, it's not well tested up to now, but that's not your
problem I assume.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> So we'd be looking at Beta on Feb 1st, with a release around Apr 1st, and > beta for 7 being around June 1st, with 7 release for Sept 1st? I don't see why we couldn't plan on a Mar 1 final, with the assumption that the beta will take one month. It may take longer, but it may not. > > IMHO, 7 is waiting for Vadim/WAL...we're doing a 6.6 due to him being > indisposed until Mar/Apr, correct? Not really. We have some big items open, but they are not very far along, except WAL, and because he can't finish for a while, it makes sense to release what we have done for the past six months. -- 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
> Tom Lane wrote: > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > Seems foreign key ability would be enough to justify a 6.6. > > > > Even without foreign keys, we have enough bugfixes in place to justify > > a 6.6 release, I think. If Jan can get some amount of foreign key > > support working before Feb, that'd be a nice bonus --- but it's not > > really necessary. > > As far as I see it now, I can get the FK stuff with MATCH > FULL ready by February first. Must be enough. Foreign key is quite complicated. It will take them a while even to ask for more than that. -- 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
> I thought Marc decided[1] last year to drop the minor.minor version > numbers. IOW, there would be no 6.6.1, 6.6.2, etc. Make the upcoming > release 7.0 and take care of any minor glitches in it as 7.1, 7.2 and > when WAL and the other stuff is ready - or as it's ready - release 8.0 > and fix any glitches as 8.1, etc. Currently every minor release is really > a major one, so why not just mark it as such and not worry about it? > > Vince. > > [1] Or did you do that on inn-workers and not here? It was about the same > time FreeBSD dropped the major.minor.minor for the major.minor numbering. I don't think it was here. I never heard about it. -- 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
> Yeah, I was thinking that if we were to call this 7.0 and have plans > for going to 8.0 as soon as WAL &etc are done, then we'd basically be > dropping one level of version number --- no need for a third number > if major revs are that close together. That's OK with me as long as > we all understand that it's a change in naming practices. There are > things we'd need to change to make it work. For example, PG_VERSION > would need to record only the top version number: 7.0 and 7.1 would be > expected to have compatible databases, not incompatible ones. Makes sense in that our 6.4->6.5 release is really a major release for other people, but if we go to the new naming, we are going to get > 10 very soon, and we will start looking like GNU Emacs at version 19 or 20. We are guilty of our own success in making such big releases. I vote we keep it the same. Our users already know every release is a major one, and very high release numbers > 10 look kind of strange to me. -- 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 Fri, 10 Dec 1999, Bruce Momjian wrote:
> Makes sense in that our 6.4->6.5 release is really a major release for
> other people, but if we go to the new naming, we are going to get > 10
> very soon, and we will start looking like GNU Emacs at version 19 or 20.
The other problem is that if we keep going with 6.5->6.6->6.x, we're gonna
hit 6.10, etc...looks funnier, IMHO...and, unless something major comes
along after WAL and all that, never go beyond 7? :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> The other problem is that if we keep going with 6.5->6.6->6.x, we're gonna
> hit 6.10, etc...looks funnier, IMHO...and, unless something major comes
> along after WAL and all that, never go beyond 7? :)
v8.0: Corba, or XML, or one of those IBM standard protocol things for
fe/be
v9.0: multiple database access
v10.0: distributed databases
v11.0: features released as M$Postgres-1.0 after M$ owns every ISP
scrappy could use, cuts off access, and takes over the sources
;) :)))
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
"D'Arcy J.M. Cain" wrote: > > Thus spake Jan Wieck > > As far as I see it now, I can get the FK stuff with MATCH > > FULL ready by February first. Must be enough. > > Any chance of getting the FK semantics into the parser right away even > though it is ignored? We do have foreign key syntax in parser hannu=> create table foreign_tab( hannu-> f int, hannu-> foreign key(f) references primary_tab (i) hannu-> ); NOTICE: CREATE TABLE/FOREIGN KEY clause ignored; not yet implemented What do you mean by semantics here ? Should it check that the primary table and field(s) exist ? ------------------ Hannu
Thus spake Hannu Krosing
> "D'Arcy J.M. Cain" wrote:
> > Any chance of getting the FK semantics into the parser right away even
> > though it is ignored?
>
> We do have foreign key syntax in parser
>
> hannu=> create table foreign_tab(
> hannu-> f int,
> hannu-> foreign key(f) references primary_tab (i)
> hannu-> );
> NOTICE: CREATE TABLE/FOREIGN KEY clause ignored; not yet implemented
>
> What do you mean by semantics here ?
> Should it check that the primary table and field(s) exist ?
Nope. That's exactly what I meant. I didn't realize that it was already
there. Sorry for the confusion.
--
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 425 1212 (DoD#0082) (eNTP) | what's for dinner.
>
> Thus spake Hannu Krosing
> > "D'Arcy J.M. Cain" wrote:
> > > Any chance of getting the FK semantics into the parser right away even
> > > though it is ignored?
> >
> > We do have foreign key syntax in parser
> >
> > hannu=> create table foreign_tab(
> > hannu-> f int,
> > hannu-> foreign key(f) references primary_tab (i)
> > hannu-> );
> > NOTICE: CREATE TABLE/FOREIGN KEY clause ignored; not yet implemented
> >
> > What do you mean by semantics here ?
> > Should it check that the primary table and field(s) exist ?
>
> Nope. That's exactly what I meant. I didn't realize that it was already
> there. Sorry for the confusion.
Caution D'Arcy,
the FOREIGN KEY syntax that's in 6.5 is a little incomplete.
Doesn't allow match type and constraint attribute
specification (deferrability and initial deferred state).
Especially the match type is required, because in 7.0 only
MATCH FULL will be implemented, not the <unspecified>
default.
As I said in another post, the constraint attr spec isn't
possible in column constraint right now in 7.0, but we're
working on it. Should be ready in a few days.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #