a225bf05e0
< * Allow major upgrades without dump/reload, perhaps using pg_upgrade < [pg_upgrade] < * Check for unreferenced table files created by transactions that were < in-progress when the server terminated abruptly < < http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php < > * Check for unreferenced table files created by transactions that were > in-progress when the server terminated abruptly > > http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php > < * Support table partitioning that allows a single table to be stored < in subtables that are partitioned based on the primary key or a WHERE < clause < creation of rules for INSERT/UPDATE/DELETE, and constraints for < rapid partition selection. Options could include range and hash > creation of triggers or rules for INSERT/UPDATE/DELETE, and constraints > for rapid partition selection. Options could include range and hash < < * Improve replication solutions < < o Load balancing < < You can use any of the master/slave replication servers to use a < standby server for data warehousing. To allow read/write queries to < multiple servers, you need multi-master replication like pgcluster. < < o Allow replication over unreliable or non-persistent links < < < o Mark change-on-restart-only values in postgresql.conf < All objects in the default database tablespace must have default < tablespace specifications. This is because new databases are < created by copying directories. If you mix default tablespace < tables and tablespace-specified tables in the same directory, < creating a new database from such a mixed directory would create a < new database with tables that had incorrect explicit tablespaces. < To fix this would require modifying pg_class in the newly copied < database, which we don't currently do. > Currently all objects in the default database tablespace must > have default tablespace specifications. This is because new > databases are created by copying directories. If you mix default > tablespace tables and tablespace-specified tables in the same > directory, creating a new database from such a mixed directory > would create a new database with tables that had incorrect > explicit tablespaces. To fix this would require modifying > pg_class in the newly copied database, which we don't currently > do. < < o Allow recovery.conf to allow the same syntax as > o Allow recovery.conf to support the same syntax as < * Allow user-defined types to specify a type modifier at table creation < time < * Allow all data types to cast to and from TEXT < < http://archives.postgresql.org/pgsql-hackers/2007-04/msg00017.php < < < o Add support for year-month syntax, INTERVAL '50-6' YEAR TO MONTH < o Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 year' AS < INTERVAL MONTH), and this should return '12 months' > o Add support for year-month syntax, INTERVAL '50-6' YEAR > TO MONTH > o Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 > year' AS INTERVAL MONTH), and this should return '12 months' < * Allow MONEY to be cast to/from other numeric data types > * Allow MONEY to be easily cast to/from other numeric data types > < * Allow functions to have a schema search path specified at creation time < * Fix cases where invalid byte encodings are accepted by the database, < but throw an error on SELECT < < http://archives.postgresql.org/pgsql-hackers/2007-03/msg00767.php < * Improve logging of prepared statements recovered during startup > * Improve logging of prepared transactions recovered during startup < * Make standard_conforming_strings the default in 8.4? > * Make standard_conforming_strings the default in 8.5? < * Allow the count returned by SELECT, etc to be to represent as an int64 > * Allow the count returned by SELECT, etc to be represented as an int64 < o Use more reliable method for CREATE DATABASE to get a consistent < copy of db? < o Fix transaction restriction checks for CREATE DATABASE and < other commands < < http://archives.postgresql.org/pgsql-hackers/2007-01/msg00133.php < currently allowed. > currently allowed. This currently is done if the table is > created inside the same transaction block as the COPY because > no other backends can see the table. < o Add SET PATH for schemas? < < This is basically the same as SET search_path. < o Enforce referential integrity for system tables < o Add Oracle-style packages (Pavel) < < A package would be a schema with session-local variables, < public/private functions, and initialization functions. It < is also possible to implement these capabilities < in all schemas and not use a separate "packages" < syntax at all. < < http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php < < o Add single-step debugging of functions < o Allow RETURN to return row or record functions < < http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php < http://archives.postgresql.org/pgsql-patches/2006-08/msg00397.php < http://archives.postgresql.org/pgsql-hackers/2006-09/msg00388.php < < o Fix problems with RETURN NEXT on tables with < dropped/added columns after function creation < < http://archives.postgresql.org/pgsql-patches/2006-02/msg00165.php < < * Make consistent use of long/short command options --- pg_ctl needs < long ones, pg_config doesn't have short ones, postgres doesn't have < enough long ones, etc. < < < < o Consider parsing the -c string into individual queries so each < is run in its own transaction < < http://archives.postgresql.org/pgsql-hackers/2007-01/msg00291.php < < < o Remove unnecessary function pointer abstractions in pg_dump source < code > o Remove unnecessary function pointer abstractions in pg_dump source > code < < < o Fix SSL retry to avoid useless repeated connection attempts and < ensuing misleading error messages > < < This is difficult because it requires datatype-specific knowledge. < < * Improve commit_delay handling to reduce fsync() < * %Add an option to sync() before fsync()'ing checkpoint files > < * Reduce lock time during VACUUM FULL by moving tuples with read lock, < then write lock and truncate table < < Moved tuples are invisible to other backends so they don't require a < write lock. However, the read lock promotion to write lock could lead < to deadlock situations. < < * Prevent long-lived temporary tables from causing frozen-xid advancement < starvation < < The problem is that autovacuum cannot vacuum them to set frozen xids; < only the session that created them can do that. < < < < o Use free-space map information to guide refilling < o Consider logging activity either to the logs or a system view > The problem is that autovacuum cannot vacuum them to set frozen xids; > only the session that created them can do that. < * Add connection pooling < < It is unclear if this should be done inside the backend code or done < by something external like pgpool. The passing of file descriptors to < existing backends is one of the difficulties with a backend approach. < < * Consider reducing memory used for shared buffer reference count < < http://archives.postgresql.org/pgsql-hackers/2007-01/msg00752.php < < * %Remove memory/file descriptor freeing before ereport(ERROR) < * %Promote debug_query_string into a server-side function current_query() < * Allow ecpg to work with MSVC and BCC < * Add xpath_array() to /contrib/xml2 to return results as an array < * Allow building in directories containing spaces < < This is probably not possible because 'gmake' and other compiler tools < do not fully support quoting of paths with spaces. < < * Fix sgmltools so PDFs can be generated with bookmarks < * Split out libpq pgpass and environment documentation sections to make < it easier for non-developers to find < * Use strlcpy() rather than our StrNCpy() macro < < http://archives.postgresql.org/pgsql-hackers/2006-09/msg02108.php < < o Re-enable timezone output on log_line_prefix '%t' when a < shorter timezone string is available < * Allow statements across databases or servers with transaction < semantics < < This can be done using dblink and two-phase commit. > * Add Oracle-style packages (Pavel) < * Add the features of packages > A package would be a schema with session-local variables, > public/private functions, and initialization functions. It > is also possible to implement these capabilities > in any schema and not use a separate "packages" > syntax at all. < o Make private objects accessible only to objects in the same schema < o Allow current_schema.objname to access current schema objects < o Add session variables < o Allow nested schemas > http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php |
||
|---|---|---|
| config | ||
| contrib | ||
| doc | ||
| src | ||
| COPYRIGHT | ||
| GNUmakefile.in | ||
| Makefile | ||
| README | ||
| README.CVS | ||
| aclocal.m4 | ||
| configure | ||
| configure.in | ||
README
PostgreSQL Database Management System ===================================== This directory contains the source code distribution of the PostgreSQL database management system. PostgreSQL is an advanced object-relational database management system that supports an extended subset of the SQL standard, including transactions, foreign keys, subqueries, triggers, user-defined types and functions. This distribution also contains C language bindings. PostgreSQL has many language interfaces including some of the more common listed below: C++ - http://thaiopensource.org/development/libpqxx/ JDBC - http://jdbc.postgresql.org ODBC - http://odbc.postgresql.org Perl - http://search.cpan.org/~dbdpg/ PHP - http://www.php.net Python - http://www.initd.org/ Ruby - http://ruby.scripting.ca/postgres/ Other language binding are available from a variety of contributing parties. PostgreSQL also has a great number of procedural languages available, a short, incomplete list is below: PL/pgSQL - included in PostgreSQL source distribution PL/Perl - included in PostgreSQL source distribution PL/PHP - http://projects.commandprompt.com/projects/public/plphp PL/Python - included in PostgreSQL source distribution PL/Java - http://pgfoundry.org/projects/pljava/ PL/Tcl - included in PostgreSQL source distribution See the file INSTALL for instructions on how to build and install PostgreSQL. That file also lists supported operating systems and hardware platforms and contains information regarding any other software packages that are required to build or run the PostgreSQL system. Changes between all PostgreSQL releases are recorded in the file HISTORY. Copyright and license information can be found in the file COPYRIGHT. A comprehensive documentation set is included in this distribution; it can be read as described in the installation instructions. The latest version of this software may be obtained at http://www.postgresql.org/download/. For more information look at our web site located at http://www.postgresql.org/.