Re: 8.2 features status

My outlook is that it isn't a lot of _new_ things that you couldn't do
before, but rather improvements of existing functionality.

---------------------------------------------------------------------------

Tom Lane wrote:
> I'm not clear on why there's all this doom and gloom about how 8.2 will
> be "merely" a performance-oriented release, with few new features, eg
> http://archives.postgresql.org/pgsql-hackers/2006-07/msg00111.php
>
> Certainly there's been a ton of effort spent on high-end performance
> issues. But a quick troll through the CVS logs shows a fair number of
> features that could be considered killer must-have things by their
> respective target audiences:
>
> multi-row VALUES, not only for INSERT but everywhere SELECT is allowed
> pg_dump multiple -n and -t options, regex patterns for object names
> multi-argument aggregates, including SQL2003-standard statistical aggregates
> fully configurable timezone abbreviations (no more 'australian_timezones' hack)
> allow full zic timezone names in datetime input values
> support comparisons like "if row(new.*) is distinct from row(old.*)"
> DROP ... IF EXISTS
> numerous tsearch2 improvements, eg thesaurus
> GIN index opclass
> GRANT CONNECT ON DATABASE
> support SSL Certificate Revocation List (CRL) files
> plpython supports named parameters, composite-type results, more result-set options
> plperl prepared queries
> domain constraint checks are now applied everywhere
> better psql multiline command handling
> error cursor position displayed for many parse-analysis errors
> standard_conforming_strings can be turned on (HUGE deal for some people)
> initdb and pg_ctl can safely start from an admin account on Windows
> display multiline values nicely in psql
> support SQL-compliant row comparisons; they can be indexscan quals
> DROP OWNED, REASSIGN OWNED for dealing with removal of a user
> null elements in arrays
>
> There are also some commits that are "mere" performance tweaks, and yet
> we should not understate their importance because they could make the
> difference between usability and non-usability in many applications:
>
> lazy vacuums are ignored by other processes; improves behavior of concurrent vacuums
> add index and table storage options (currently only FILLFACTOR)
> stats_command_string overhead reduced to near zero, now on by default
> reduce locking involved in DATABASE commands, eg CREATE DATABASE no longer blocks incoming connections
> constraint exclusion works for UPDATE and DELETE
> constraint exclusion works for UNION ALL views, not only inheritance trees
> planner can rearrange join order for many common OUTER JOIN scenarios
>
> And that's not counting some pretty significant submitted-but-not-yet-
> reviewed patches (sure, some of these may get rejected, but they're all
> open possibilities today):
>
> online index builds
> bitmap index AM
> updatable views
> PL plugin patch (plpgsql debugger infrastructure)
> restartable recovery (allow checkpoints for a hot-standby server)
> INSERT/UPDATE RETURNING
>
> Not that there's anything wrong with a performance-oriented release
> ... but if you think that 8.2 is short on features, you'd better get
> ready to be disappointed by every future release. There's not all
> that much stuff left to do in terms of raw language "features".
> (Of course the SQL committee keeps inventing a ton of new stuff every
> few years, but how much of that do you really care about?)
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +