PostgreSQL 8.3.4.1

PostgreSQL is a powerful, open source relational database system.
PostgreSQL has more than 15 years of active development and a proven architecture that has earned it a strong reputation for reliability, data integrity, and correctness.
PostgreSQL runs on all major operating systems, including Linux, UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64), and Windows.
PostgreSQL is fully ACID compliant, has full support for foreign keys, joins, views, triggers, and stored procedures (in multiple languages). It includes most SQL92 and SQL99 data types, including INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, and TIMESTAMP.
PostgreSQL will also support storage of binary large objects, including video, sounds, or pictures.
PostgreSQL has native programming interfaces for C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, among others, and exceptional documentation.
An enterprise class database, PostgreSQL boasts sophisticated features such as Multi-Version Concurrency Control (MVCC), point in time recovery, tablespaces, asynchronous replication, nested transactions (savepoints), online/hot backups, a sophisticated query planner/optimizer, and write ahead logging for fault tolerance.
PostgreSQL supports international character sets, multibyte character encodings, Unicode, and it is locale-aware for sorting, case-sensitivity, and formatting.
PostgreSQL is highly scalable both in the sheer quantity of data it can manage and and in the number of concurrent users it can accommodate.
There are active PostgreSQL systems in production environments that manage in excess of 4 terabytes of data.

Enhancements:
- Full text search is now a built-in feature
- Support for the SQL/XML standard, including a new xml builtin data type
- enum data types
- UUID data type, similar to that defined by RFC 4122
- Arrays of composite types
- ORDER BY ... NULLS FIRST/LAST
- Updatable cursors (UPDATE/DELETE WHERE CURRENT OF cursor_name)
- Per-function parameter settings
- User-defined types can now have type modifiers (parameters)
- Declarations such as varchar(42) are no longer restricted to use by built-in data types.
- Automatic plan invalidation when table definitions change. This will particularly ease usage of temporary tables in PL/PgSQL functions.
- Numerous improvements in logging and statistics collection capabilities, including the ability to emit postmaster log messages in CSV format that can be directly loaded into a database table for analysis
- SSPI/GSSAPI authentication support
- Multiple autovacuum worker processes, and other autovacuum improvements. Autovacuum is now considered mature enough to be enabled by default.
- The entire PostgreSQL system can now be compiled with Microsoft Visual C
- This will improve the ability of Windows-based developers to contribute to the project. Windows executables made with Visual C may also have better stability and performance than those made with other tool sets.
- Asynchronous commit option to allow transactions to be reported committed before they have actually been flushed to disk. This would not, of course, be acceptable if the client takes some critical external action on the assumption that the transaction will be remembered; but for certain applications, it is an acceptable risk for some or all transactions to use this mode. Unlike existing options such as fsync, asynchronous commit does not risk database corruption; the worst case is that after a crash, the last few reportedly-committed transactions will not have taken effect.
- "Distributed" checkpoints to spread out the I/O load of a checkpoint
- Heap-Only Tuples (HOT) to reduce overhead of updates
- Just-in-time background writer strategy to improve disk write efficiency
- Reduction of on-disk data size through reducing both per-tuple and per-field overheads
- Efficiency improvements for large sequential scans, including prevention of cache flushing and "piggybacking" to let concurrent scans read the table only once
- Top-N sorting
- Lazy XID assignment to reduce the cost of read-only transactions. For applications in which there are a large number of read-only transactions, this helps not only by reducing overhead for the transactions themselves, but by reducing overhead thats driven by the rate of XID consumption; notably, reducing contention for transaction log buffers and reducing the frequency of anti-wraparound vacuuming.