Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> The problem there was not the feature freeze, it was that we kept
>> slipping the beta date while we waited around for certain items
>> to get done. The lesson I take away from the past couple releases
>> is that you set a target beta date and then stick to it; features
>> that aren't in on time don't get extensions.
> OK, let's follow that logic. Do we have enough to justify a release
> without any of those features? I don't think so.
Sure we do. A quick scan of the CVS logs reminds me that we have
already done a bunch of stuff:
btree index space recycling
free-space-map management improvements
IN, NOT IN via hashtables and/or joins
hash-based aggregation
merge/hash on expressions more complex than simple Vars
deduction of equality on expressions other than simple Vars
hash joins can use more than one join key
smarter planning of outer joins
join syntax doesn't necessarily constrain plan
smarter planning of nestloop inner indexscans with multiple outer relations
new regex library
domain CHECK constraints
ALTER DOMAIN
grant options, cascaded revoke
print more information about deadlocks
information schema
read-only transactions
first-class COALESCE and NULLIF constructs (no duplicate evaluation)
IPv6 connections
Simple SQL functions expand into inline expressions
Eliminate memory leaks in SQL functions
CLUSTER ALL
transaction-safe TRUNCATE
FOR EACH STATEMENT triggers
ON COMMIT PRESERVE/DELETE ROWS for temp tables
(plus lots more minor things) --- and we still have a couple months of
development left. I don't see a good reason to delay releasing these
features if other ones aren't ready.
regards, tom lane
