diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html index 9222dde60a4790fca48fb202eeb030121420cffc..076431b275c4bb555c3e1f46c605807803d441c5 100644 --- a/doc/src/FAQ/TODO.html +++ b/doc/src/FAQ/TODO.html @@ -8,7 +8,7 @@
Current maintainer: Bruce Momjian (bruce@momjian.us)
-Last updated: Tue Aug 14 13:02:38 EDT 2007
+Last updated: Wed Aug 15 11:36:16 EDT 2007
The most recent version of this document can be viewed at
http://www.postgresql.org/docs/faqs.TODO.html.
@@ -26,14 +26,14 @@ first. There is also a developer's wiki at
http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php
Lock table corruption following SIGTERM of an individual backend
has been reported in 8.0. A possible cause was fixed in 8.1, but
it is unknown whether other problems exist. This item mostly
@@ -73,7 +73,7 @@ first. There is also a developer's wiki at
Currently ALTER USER and ALTER DATABASE support per-user and per-database defaults. Consider adding per-user-and-database - defaults so things like search_path can be defaulted for a + defaults so things like search_path can be defaulted for a specific user connecting to a specific database.
If the TIMESTAMP value is stored with a time zone name, interval +
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-sql/2006-10/msg00059.php
@@ -323,13 +323,13 @@ first. There is also a developer's wiki at
Some special format flag would be required to request such - accumulation. Such functionality could also be added to EXTRACT. + accumulation. Such functionality could also be added to EXTRACT. Prevent accumulation that crosses the month/day boundary because of the uneven number of days in a month.
On crash recovery, the table involved in the COPY would be removed or have its heap and index files truncated. One - issue is that no other backend should be able to add to - the table at the same time, which is something that is + issue is that no other backend should be able to add to + the table at the same time, which is something that is currently allowed.
http://archives.postgresql.org/pgsql-patches/2006-02/msg00288.php
@@ -753,7 +753,7 @@ first. There is also a developer's wiki at
than toggle
Consider using auto-expanded mode for backslash commands like \df+.
PQfnumber() should never have been doing lowercasing, but +
PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it
Currently all statement results are transferred to the libpq
- client before libpq makes the results available to the
+ client before libpq makes the results available to the
application. This feature would allow the application to make
use of the first result rows while the rest are transferred, or
held on the server waiting for them to be requested by libpq.
@@ -997,15 +997,15 @@ first. There is also a developer's wiki at
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php
Currently indexes do not have enough tuple visibility information - to allow data to be pulled from the index without also accessing - the heap. One way to allow this is to set a bit on index tuples - to indicate if a tuple is currently visible to all transactions - when the first valid heap lookup happens. This bit would have to - be cleared when a heap tuple is expired. +
Currently indexes do not have enough tuple visibility information + to allow data to be pulled from the index without also accessing + the heap. One way to allow this is to set a bit on index tuples + to indicate if a tuple is currently visible to all transactions + when the first valid heap lookup happens. This bit would have to + be cleared when a heap tuple is expired.
Another idea is to maintain a bitmap of heap pages where all rows
- are visible to all backends, and allow index lookups to reference
+ are visible to all backends, and allow index lookups to reference
that bitmap to avoid heap lookups, perhaps the same bitmap we might
add someday to determine which heap pages need vacuuming. Frequently
accessed bitmaps would have to be stored in shared memory. One 8k
@@ -1080,7 +1080,7 @@ first. There is also a developer's wiki at
http://archives.postgresql.org/pgsql-hackers/2006-06/msg01305.php http://archives.postgresql.org/pgsql-hackers/2006-06/msg01534.php
- http://archives.postgresql.org/pgsql-patches/2007-03/msg00358.php
@@ -1186,18 +1186,18 @@ first. There is also a developer's wiki at
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 + 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.
To do this, only a single writer can modify the table, and writes +
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 + crash recovery. Readers can continue accessing the table. Such + tables probably cannot have indexes. One complexity is the handling of indexes on TOAST tables.
This might replace GEQO, http://sixdemonbag.org/Djinni.
-http://archives.postgresql.org/pgsql-hackers/2007-01/msg00096.php
@@ -1254,7 +1254,7 @@ first. There is also a developer's wiki at http://archives.postgresql.org/pgsql-patches/2007-05/msg00046.php
@@ -1415,8 +1415,8 @@ first. There is also a developer's wiki at
While PostgreSQL clients runs fine in limited-resource environments, the server requires multiple processes and a stable pool of resources to - run reliabily and efficiently. Stripping down the PostgreSQL server - to run in the same process address space as the client application + run reliabily and efficiently. Stripping down the PostgreSQL server + to run in the same process address space as the client application would add too much complexity and failure cases.