From a3faf37f49025a0a4f5dc31479c54e6b84dab07a Mon Sep 17 00:00:00 2001
From: Alvaro Herrera http://archives.postgresql.org/pgsql-hackers/2006-11/msg00390.php
http://archives.postgresql.org/pgsql-hackers/2006-01/msg00250.php http://archives.postgresql.org/pgsql-hackers/2006-01/msg00250.php
+ http://archives.postgresql.org/pgsql-bugs/2006-04/msg00248.php
The SQL standard states that the units after the string
- specify the units of the string, e.g. INTERVAL '2' MINUTE
- should return '00:02:00'. The current behavior has the units
- restrict the interval value to the specified unit or unit
- range, INTERVAL '70' SECOND returns '00:00:10'.
- For syntax that isn't uniquely ISO or PG syntax, like '1' or
- '1:30', treat as ISO if there is a range specification clause,
- and as PG if there no clause is present, e.g. interpret '1:30'
- MINUTE TO SECOND as '1 minute 30 seconds', and interpret
- '1:30' as '1 hour, 30 minutes'.
- This makes common cases like SELECT INTERVAL '1' MONTH
- SQL-standard results. The SQL standard supports a limited
- number of unit combinations and doesn't support unit names in
- the string. The PostgreSQL syntax is more flexible in the
- range of units supported, e.g. PostgreSQL supports '1 year 1
- hour', while the SQL standard does not.
- The SQL standard states that the units after the string
+ specify the units of the string, e.g. INTERVAL '2' MINUTE
+ should return '00:02:00'. The current behavior has the units
+ restrict the interval value to the specified unit or unit
+ range, INTERVAL '70' SECOND returns '00:00:10'.
+ For syntax that isn't uniquely ISO or PG syntax, like '1' or
+ '1:30', treat as ISO if there is a range specification clause,
+ and as PG if there no clause is present, e.g. interpret '1:30'
+ MINUTE TO SECOND as '1 minute 30 seconds', and interpret
+ '1:30' as '1 hour, 30 minutes'.
+ This makes common cases like SELECT INTERVAL '1' MONTH
+ SQL-standard results. The SQL standard supports a limited
+ number of unit combinations and doesn't support unit names in
+ the string. The PostgreSQL syntax is more flexible in the
+ range of units supported, e.g. PostgreSQL supports '1 year 1
+ hour', while the SQL standard does not.
+ http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php
contrib/lo offers this functionality.
This requires the TOAST column to be stored EXTERNAL.
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00781.php
http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php
http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php
http://archives.postgresql.org/pgsql-hackers/2007-11/msg00511.php
http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php
http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php
http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php
http://archives.postgresql.org/pgsql-patches/2008-03/msg00062.php
PostgreSQL TODO List
@@ -286,94 +286,92 @@ first. There is also a developer's wiki at
LC_MESSAGES
- http://archives.postgresql.org/pgsql-bugs/2006-04/msg00248.php
+
-
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
Functions
@@ -431,7 +429,7 @@ first. There is also a developer's wiki at
Index functions are safe, so VACUUM and ANALYZE are safe too. +
Index functions are safe, so VACUUM and ANALYZE are safe too. Triggers, CHECK and DEFAULT expressions, and rules are still vulnerable. http://archives.postgresql.org/pgsql-hackers/2008-01/msg00268.php
@@ -493,7 +491,7 @@ first. There is also a developer's wiki athttp://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php
@@ -788,12 +786,10 @@ first. There is also a developer's wiki athttp://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php +
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php
-Currently LISTEN/NOTIFY information is stored in pg_listener. +
Currently LISTEN/NOTIFY information is stored in pg_listener. Storing such information in memory would improve performance.
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00417.php
@@ -1106,8 +1102,8 @@ first. There is also a developer's wiki at
Right now all deferred trigger information is stored in backend
@@ -1239,24 +1235,23 @@ first. There is also a developer's wiki at
digital trees (see Aoki)
http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php -
-Currently only one hash bucket can be stored on a page. Ideally several hash buckets could be stored on a single page and greater granularity used for the hash algorithm.
http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php
- A third idea would be for a heap scan to check if all rows are visible
- and if so set a per-table flag which can be checked by index scans.
+ and if so set a per-table flag which can be checked by index scans.
Any change to the table would have to clear the flag. To detect
changes during the heap scan a counter could be set at the start and
checked at the end --- if it is the same, the table has not been
@@ -1331,12 +1326,9 @@ first. There is also a developer's wiki at
http://archives.postgresql.org/pgsql-patches/2008-01/msg00049.php
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00823.php +
http://archives.postgresql.org/pgsql-hackers/2005-10/msg01419.php
@@ -1401,7 +1393,7 @@ first. There is also a developer's wiki athttp://archives.postgresql.org/pgsql-hackers/2006-12/msg00876.php
- The problem is that autovacuum cannot vacuum them to set frozen xids;
only the session that created them can do that.
@@ -1420,7 +1412,7 @@ first. There is also a developer's wiki at
http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php
@@ -1575,7 +1567,7 @@ first. There is also a developer's wiki athttp://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php
http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php
-http://archives.postgresql.org/pgsql-performance/2008-01/msg00023.php
A package would be a schema with session-local variables,
public/private functions, and initialization functions. It
is also possible to implement these capabilities
@@ -1850,7 +1842,7 @@ first. There is also a developer's wiki at
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php