Re: [HACKERS] When is 7.0 going Beta?

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I know that we made the commitment for v7.0 (and that waffling on that
> issue for past releases drove me nuts ;), but I suspect that what we
> already have in the code tree could come close to standing on its own
> (especially in light of easily disabling the WAL framework, per
> Vadim's note).

As Bruce's list reminds us, there are a lot of nice fixes in place
already.  I'm not changing my vote (yet), but let's just think a little
further on this...

Considering Bruce's "major items":

WAL: if we can turn it off and leave it in the tree, then this could be
postponed past a 6.6 release.

Foreign keys: Jan has made some commits; features are there but probably
rather broken.  As long as the FK stuff is unlikely to break any *existing*
functionality (Jan, do you think that's a safe assumption?) it'd be OK
to leave it in the tree, documented as "work in progress, use at your
own risk".  Getting feedback from users might actually help with the
debugging here.

Date/Time types: no commits yet, but because of compatibility issues
we'd want to postpone this to 7.0 anyway.

Function arg changes: same comments.  However, we'd have to plug in
Uncle George's Alpha fixes instead.  Those are ugly, but I could live
with them as a short-term hack.

Optimizer: really needs some work, but perhaps not very much to get to a
releasable state.  Much of what I'd hoped to do for 7.0 could be put off.

Outer joins: As yet no commits, and I'd be inclined to say "leave it
that way for 6.6".

Long tuples: not started, postpone to 7.0.

Query tree redesign: not started, postpone to 7.0.


Things Bruce didn't list:

psql: not ready for prime time, according to Peter (who should know ;-)).

Table locking/SI handling: also not ready for prime time.

Long queries: although this area is almost done, we cannot release
without fixing pg_dump, else it will choke on complex table definitions
and rules that are now possible.  Michael Ansley is working on this ---
Michael, do you have an ETA?  I think there were some loose ends in
some of the interface libraries, too.


So, if we refocused our energies into cleaning up these items, we
probably could make a reasonable 6.6 release.  I'd have to say that
1 Jan is too soon for beta freeze --- dunno about you guys, but family
commitments and Christmas shopping are going to be soaking up most of my
spare cycles through New Year's Day.  I can't promise to get much of
anything done until January.  1 Feb would be a reasonable date for me.
I think Hiroshi and I could have the locking stuff solved by then, and
I could find some time to do what must be done in the optimizer.  If
Peter can have psql in a presentable state by 1 Feb, it could work.

There is an awful lot to be said for finishing undone work and getting
it out the door to people who need it.  Bruce has a good point about
how difficult it is to remember what you were doing 6 months ago.
On the other hand, if we do this then serious 7.0 feature development
will probably not resume till about May, which is a long way off.
Maybe that's a good tradeoff for consolidating our current gains and
getting a beta-test cycle under our belts for what we have already done.

Comments?  What other stuff do we have in progress that needs to be
taken into account?

At this point I'm sitting on the fence --- I can see the arguments for
going either way.  But I think I might be leaning in favor of a 6.6,
unless someone points out an issue I missed.
        regards, tom lane