To: "Joshua D. Drake" <jd@commandprompt.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: Getting a move on for 8.2 beta 
In-reply-to: <44F87F02.9050300@commandprompt.com> 
References: <5364.1157125854@sss.pgh.pa.us>
	<44F87F02.9050300@commandprompt.com>
Comments: In-reply-to "Joshua D. Drake" <jd@commandprompt.com>
	message dated "Fri, 01 Sep 2006 11:42:10 -0700"
Date: Fri, 01 Sep 2006 16:10:01 -0400
Message-ID: <20304.1157141401@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Joshua D. Drake" <jd@commandprompt.com> writes:
>> My feeling is that we ought to bounce bitmap indexes and updatable views
>> as not being ready, accept all the contrib stuff, and try to get the
>> other items done in time for a beta at, say, the end of next week.

> I know there is a lot of "backend" work that has been done for 8.2 but 
> the two features you are suggesting we bounce, are probably the most 
> visible of marketable features we will have for this release. Especially 
> updateable views.

Josh said nearly the same in core's discussion, but come now.  The
updateable-view patch (in its current form) does not offer *one single
thing* you can't do today, indeed for many PG releases past; it just
saves writing out some tedious rules.  If that's the most marketable
feature in 8.2 we're already in trouble.  I don't think it is anyway.
Looking at the CVS logs I see

	INSERT/UPDATE/DELETE RETURNING
	VALUES lists
	CREATE INDEX CONCURRENTLY
	pl/pgsql debugger (OK, not in core, but available)
	restartable WAL recovery
	constraint exclusion works on UPDATE/DELETE queries
	multiple-argument aggregate functions
	SQL2003-standard statistical aggregates
	COPY (SELECT ...) TO ...
	pg_dump selectivity options
	customizable timezone names
	GIN indexes
	FILLFACTOR for indexes and tables

and that's just back to the beginning of July, so it probably represents
about a quarter of the work that's gone into 8.2, but I got tired of
reading the logs at that point.

We have this discussion every single release cycle: "hey, if we wait X
amount more time then we can have cool features Y and Z".  But there's
always another X, Y, and Z.  More importantly, this view ignores the
very real disadvantages of not getting already-finished cool features
A through W out to our users sooner.

			regards, tom lane