Bruce Momjian a225bf05e0 Update TODO list based on 8.3 completed items: ... < * 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		2007-12-30 03:22:53 +00:00
..
FAQ	Update TODO list based on 8.3 completed items:	2007-12-30 03:22:53 +00:00
sgml	Document how to control the disk write cache on Solaris.	2007-12-29 17:55:07 +00:00
Makefile	Don't ship spi_* man pages. (We don't do that anyway, but now it's automatic.)	2006-12-02 01:25:50 +00:00