Re: Two weeks to feature freeze

On Wed, 2003-06-18 at 23:07, Tom Lane wrote:
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> > What about the nested transaction stuff?
> 
> With all due respect to Alvaro et al, I can't imagine that that will
> make it into 7.4.  (I have no confidence that PITR or Win32 native port
> will make it either...)
> 

Heres hoping for win32, that is a killer feature for so many people and
we're so close to it...

> > Do we have any "killer" features added to 7.4 that we can shout about?
> 
> We have a lot of pretty good stuff.  You're not happy that the
> performance of IN (subselect) has been fixed?  That btree index bloat is
> fixed (at least in large part, it remains to be seen whether the field
> performance is all that we need...)?
> 

I think the auto vacuum work will be pretty big, and I personally think
statement level triggers are pretty important too. (Which reminds me I
really need to start banging on those a bit more.)

> In my opinion the project is not at a state where whizzy new Features
> with a capital F are going to jump out of the woodwork.  We are making
> good advances in performance, reliability, SQL spec compliance, and
> stuff like that, but fancy-sounding bullet points are hard to come by.
> 

You mean like that other database that just recently added transaction
support ;-) 

I do see a number of capital F features that haven't been done yet,
win32, replication, nested transactions... imho those features could
each warrant a development cycle on their own.

> I can tell you that Red Hat's CCM group (the former Ars Digita) is
> waiting with bated breath for 7.4, because it fixes a number of problems
> (IN-subselect being one) that prevent 7.3 from being a serious
> competitor to Oracle for their platform.  7.4 is a killer release for
> them, and has been since about February, and they're getting tired of
> waiting.  I think a lot of other people are in the same situation,
> even though they may not know it ;-)
> 
> We can't slip this puppy any more --- it's time to wrap her up and
> push her out.
> 

Well, I suppose that history has shown that waiting on specific features
causes trouble with postgresql development, but I don't see why a
release can't be based around waiting for feature x as long as feature x
is being actively worked on by trusted developers who have an endgame in
sight.

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL