pgsql: Update TODO list based on 8.3 completed items: < * Allow major
Log Message:
-----------
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 abruptlyhttp://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
Modified Files:
--------------
pgsql/doc:
TODO (r1.2233 -> r1.2234)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/TODO?r1=1.2233&r2=1.2234)
pgsql/doc/src/FAQ:
TODO.html (r1.742 -> r1.743)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/TODO.html?r1=1.742&r2=1.743)
momjian@postgresql.org (Bruce Momjian) writes:
[ another long log message ]
May I suggest that it is neither necessary nor appropriate for CVS
commit messages to embody the whole diff?
Anyone who wants the diff is one click away from it anyway.
I think we could do with less bloat of the CVS archive and the
mail list archives.
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
momjian@postgresql.org (Bruce Momjian) writes:
[ another long log message ]
May I suggest that it is neither necessary nor appropriate for CVS
commit messages to embody the whole diff?
In fairness usually TODO commits are nigh one-liners. The diff is shorter and
clearer than a message describing the description of the todo item.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
Tom Lane wrote:
momjian@postgresql.org (Bruce Momjian) writes:
[ another long log message ]
May I suggest that it is neither necessary nor appropriate for CVS
commit messages to embody the whole diff?Anyone who wants the diff is one click away from it anyway.
I think we could do with less bloat of the CVS archive and the
mail list archives.
OK. Sometimes I use the diff as the actual commit but in this case it
wasn't necessary.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +