From 883b6a8a5196305b54d9ac37a190d283eb812b36 Mon Sep 17 00:00:00 2001
From: Bruce Momjian Current maintainer: Bruce Momjian (bruce@momjian.us) The most recent version of this document can be viewed at A hyphen, "-", marks changes that will appear in the upcoming 8.3 release. Bracketed items, "[]", have more detail.
- This list contains all known PostgreSQL bugs and feature requests. If http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php
If the TIMESTAMP value is stored with a time zone name, interval
computations should adjust based on the time zone rules.
+ http://archives.postgresql.org/pgsql-hackers/2004-10/msg00705.php
PostgreSQL TODO List
-Last updated: Thu Apr 17 16:56:51 EDT 2008
+Last updated: Sat Apr 19 08:15:19 EDT 2008
http://www.postgresql.org/docs/faqs.TODO.html.
@@ -16,8 +16,6 @@ Last updated: Thu Apr 17 16:56:51 EDT 2008
A percent sign, "%", marks items that are easier to implement.
you would like to work on an item, please read the Developer's FAQ
first. There is also a developer's wiki at
@@ -149,7 +147,6 @@ first. There is also a developer's wiki at
database creation might have locale-aware indexes. The indexes would
need to be reindexed to match the new locale.
Right now only one encoding is allowed per database. [locale] +
Right now only one encoding is allowed per database.
http://archives.postgresql.org/pgsql-hackers/2005-03/msg00932.php + http://archives.postgresql.org/pgsql-patches/2005-08/msg00039.php http://archives.postgresql.org/pgsql-patches/2005-08/msg00309.php + http://archives.postgresql.org/pgsql-hackers/2005-09/msg00110.php + http://archives.postgresql.org/pgsql-patches/2005-09/msg00020.php + http://archives.postgresql.org/pgsql-hackers/2005-12/msg01121.php + http://archives.postgresql.org/pgsql-hackers/2006-01/msg00767.php http://archives.postgresql.org/pgsql-patches/2006-03/msg00233.php http://archives.postgresql.org/pgsql-hackers/2006-09/msg00662.php http://wiki.postgresql.org/wiki/Todo:Collate http://wiki.postgresql.org/wiki/Todo:ICU
-http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php
This is similar to UPDATE, then for unmatched rows, INSERT. - Whether concurrent access allows modifications which could cause - row loss is implementation independent. -
-To implement this cleanly requires that the table have a unique index - so duplicate checking can be easily performed. It is possible to - do it without a unique index if we require the user to LOCK the table - before the MERGE. +
MERGE is typically used to merge two tables. REPLACE or UPSERT + command does UPDATE, or on failure, INSERT. This is similar to UPDATE, + then for unmatched rows, INSERT. Whether concurrent access allows + modifications which could cause row loss is implementation independent. + To implement this cleanly requires that the table have a unique index + so duplicate checking can be easily performed. It is possible to do it + without a unique index if we require the user to LOCK the table before + the MERGE.
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00501.php
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00536.php
@@ -872,9 +872,10 @@ first. There is also a developer's wiki at
This would allow non-psql clients to pull the same information out of the database as psql. + http://archives.postgresql.org/pgsql-hackers/2004-01/msg00191.php
http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php
@@ -1331,7 +1332,7 @@ first. There is also a developer's wiki at
This would prevent the overhead associated with process creation. Most
operating systems have trivial process creation time compared to
database startup overhead, but a few operating systems (Win32,
@@ -1342,11 +1343,12 @@ first. There is also a developer's wiki at
Currently, to protect against partial disk page writes, we write full page images to WAL before they are modified so we can correct any partial page writes during recovery. These pages can also be eliminated from point-in-time archive files. + http://archives.postgresql.org/pgsql-hackers/2002-06/msg00655.php
Currently fsync of WAL requires the disk platter to perform a full rotation to fsync again. One idea is to write the WAL to different offsets that might reduce the rotational delay. + http://archives.postgresql.org/pgsql-hackers/2002-11/msg00483.php
Allow tables to bypass WAL writes and just fsync() dirty pages on commit. This should be implemented using ALTER TABLE, e.g. ALTER TABLE PERSISTENCE [ DROP | TRUNCATE | DEFAULT ]. Tables using non-default logging should not use referential integrity with default-logging tables. A table without dirty buffers during a crash could perhaps avoid the drop/truncate. + http://archives.postgresql.org/pgsql-hackers/2005-12/msg01016.php
To do this, only a single writer can modify the table, and writes must happen only on new pages so the new pages can be removed during crash recovery. Readers can continue accessing the table. Such tables probably cannot have indexes. One complexity is the handling of indexes on TOAST tables. + http://archives.postgresql.org/pgsql-hackers/2005-12/msg01016.php
This should be done utilizing the same infrastructure used for -- cgit v1.2.3