forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commita225bf0
committed
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.php1 parent835a51c commita225bf0