PostgresQL 8.4 beta will be out any day and 8.4 official release will hopefully not be too far behind. As we wait patiently for the official release,
Robert Treat has summarized nicely all the new features you can expect in 8.4.
PostgreSQL 8.4 is what I like to call an earth-shattering release because it has so many big ticket items in there, but also some long-needed usability features in it.
While we all know about the Windowing functions and CTEs and Recursive CTEs, there are a couple of usability features that we always get beat up on, which I am glad to see will be in 8.4.
Ability to add new columns to a view with CREATE OR REPLACE without having to drop the view and all the view dependents
Now the other niceties and usuability features which are nice but not quite as top of our list as the aforementioned.
Note this far from an exhaustive list, but Robert Treat's 8.4 slide presentaton is pretty exhaustive:
Variadic functions -- these are functions that have default values defined so can be called with varying arguments. To achieve this before you would have had to create
a separate function that calls the first and passes in the default arg. NOte this can be done with any pl langauge and in fact we demonstrated its use in PL/Python PL/Python and default parameters.
All plpgsql language and other non-sql/non-c proc languages that return sets to be called in the SELECT clause. To get around this problem before, you'd create your sophisticated
set returning function in plpgsql or python or whatever and then wrap it in an SQL function. No need for that hack anymore. Again we demonstrated this feature in PL/Python Pl/Python for loops and returning sets
pg_terminate_backend -- this kills a backend PostgreSQL process instead of just cancelling the query running on it as pg_cancel_backend did
Faster Restore -- now Restore can use parallel threads
RETURN QUERY EXECUTE support in plpgsql
LIMIT clause can take a subquery -- SELECT a.field1, a.field2 FROM a LIMIT (SELECT COUNT(*)/10 FROM a)
Make As alias in column SELECT optional as the ANSI SQL Standard allows. So you can now do - SELECT a field1, b field2 .... This is not something we would suggest since we find it makes
code hard to read, but does make code that used this regrettable syntax more portably converted to PostgreSQL. It would be nice if this were a flag though in the config that can be turned on since
I find it to be bad practice and encouraging bad habits.
Numerours changes to EXPLAIN to show columns used, maintenance improvements such as dead-locking reporting