Re: [HACKERS] When is 7.0 going Beta?

Here's my "fear"...we go beta on jan 1st, for a 6.6 ... if last beta was
any indication, we're talking 2-3 months of beta, so March/April before we
do a release, which disrupts everything that those working on v7.0
features is working on...plus, while debugging, it distracts them from
that work.

If we wait to break into Beta around June 1st, we're still going tobe
talking 2-3mos of beta work, max, so Sept 1 or so for a release...

We're to the point of "competing with the big boys"...how often does
Oracle release?  

How about this?  Out of the list below, how many can be *safely*
back-patched to the -STABLE tree?  The kind of thing where ppl are
*confident* enough that we could put out a v6.5.4 based on those patches?

I would rather see the *safe* ones backpatched and a v6.5.4 released, then
tie up ppl working v7.0 features with debugging an interim release, but
that's just me :(


On Mon, 6 Dec 1999, Bruce Momjian wrote:

> > 
> > 
> > What do we have now for a v6.6?  I'm not against, just wondering if we
> > have enough to warrant a v6.6, that's all...
> > 
> 
> Just from completed TODO list items I have many.  This doesn't count the
> non-list items like the psql rewrite and other big stuff that never made
> it to this list.  If this gets people interested, I can generate a full
> log dump to show the items.
> 
> 
> * -Recover or force failure when disk space is exhausted(Hiroshi)
> * -INSERT INTO ... SELECT with AS columns matching result columns problem
> * -Select a[1] FROM test fails, it needs test.a[1](Tom)
> * -Array index references without table name cause problems [array](Tom)
> * -INSERT ... SELECT ... GROUP BY groups by target columns not source columns(Tom)
> * -CREATE TABLE test (a char(5) DEFAULT text '', b int4) fails on INSERT(Tom)
> * -UNION with LIMIT fails
> * -CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
> * -CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction
> * -mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
> * -select * from pg_class where oid in (0,-1)
> * -SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes
> * -require SELECT DISTINCT target list to have all ORDER BY columns
> * -When using aggregates + GROUP BY, no rows in should yield no rows out(Tom)
> * -Allow HAVING to use comparisons that have no aggregates(Tom)
> * -Eliminate limits on query length
> * -Fix memory leak for aggregates(Tom)
> * -Allow compression of large fields or a compressed field type
> * -Allow pg_descriptions when creating tables
> * -Allow pg_descriptions when creating types, columns, and functions
> * -Add index on NUMERIC/DECIMAL type(Jan)
> * -Move LIKE index optimization handling to the optimizer(Tom)
> * -Allow psql \copy to allow delimiters
> * -Add a function to return the last inserted oid, for use in psql scripts
> * -Allow psql to print nulls as distinct from "" [null]
> * -Certain indexes will not shrink, i.e. oid indexes with many inserts(Vadim)
> * -Allow WHERE restriction on ctid(Hiroshi)
> * -Transaction log, so re-do log can be on a separate disk by
> * -Allow subqueries in target list
> * -Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
> * -Allow transaction commits with rollback with no-fsync performance [fsync](Vadim)
> * -Prevent fsync in SELECT-only queries(Vadim)
> * -Convert function(constant) into a constant for index use(Tom)
> * -Make index creation use psort code, because it is now faster(Vadim)
> * -Allow creation of sort temp tables > 1 Gig
> * -Allow optimizer to prefer plans that match ORDER BY(Tom)
> * -Fix memory exhaustion when using many OR's [cnfify](Tom)
> * -Process const = const parts of OR clause in separate pass(Tom)
> * -Add needed includes and removed unneeded include files(Bruce)
> * -Make configure --enable-debug add -g on compile line
> 
> -- 
>   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
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org