| Age | Commit message (Collapse) | Author |
|---|
|
> o Allow recovery.conf to allow the same syntax as
> postgresql.conf, including quoting
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00497.php
|
|
|
|
* Reduce checkpoint performance degredation by forcing data to disk
more evenly
> http://archives.postgresql.org/pgsql-patches/2006-12/msg00104.php
|
|
* Allow sequential scans to take advantage of other concurrent
sequential scans, also called "Synchronised Scanning"
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00784.php
|
|
> * Reduce checkpoint performance degredation by forcing data to disk
> more evenly
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00337.php
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00079.php
|
|
o Fix RENAME to work on variables other than OLD/NEW
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg01587.php
|
|
Windows. Per Magnus Hagander, this is not recommended.
|
|
> o Allow column display reordering by recording a display,
> storage, and permanent id for every column?
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php
>
|
|
Security: CVE-2007-0555, CVE-2007-0556
|
|
|
|
"can't" -> "cannot" section.
|
|
shared hardware section, and mention DRBD as a popular solution.
|
|
|
|
o Add long file support for binary pg_dump output
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00551.php
|
|
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
|
|
|
|
behavior has changed.
|
|
Daojing.Zhou
|
|
< http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00568.php
>
|
|
>
> * Tighten function permission checks
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php
>
|
|
>
> * Tighten trigger permission checks
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php
>
|
|
and --password for pg_dump, pg_dumpall and pg_restore, per complaint by
Michael Schmidt. Patch from Magnus Hagander.
|
|
>
> * Fix problem when multiple subtransactions of the same outer transaction
> hold different types of locks, and one subtransaction aborts
>
> http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php
|
|
created and increments. The old docs created the sequence, then showed
a nextval() of 114.
|
|
o Fix RENAME to work on variables other than OLD/NEW
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg01615.php
|
|
appropriate.
|
|
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
|
|
|
|
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
|
|
|
|
In this case extractQuery should returns -1 as nentries. This changes
prototype of extractQuery method to use int32* instead of uint32* for
nentries argument.
Based on that gincostestimate may see two corner cases: nothing will be found
or seqscan should be used.
Per proposal at http://archives.postgresql.org/pgsql-hackers/2007-01/msg01581.php
PS tsearch_core patch should be sightly modified to support changes, but I'm
waiting a verdict about reviewing of tsearch_core patch.
|
|
o Fix RENAME to work on variables other than OLD/NEW
>
> http://archives.postgresql.org/pgsql-hackers/2002-03/msg00591.php
>
|
|
|
|
|
|
>
> * Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY
>
> This is difficult because you must upgrade to an exclusive table lock
> to replace the existing index file. CREATE INDEX CONCURRENTLY does not
> have this complication. This would allow index compaction without
> downtime.
|
|
< reindex rather than update the index.
> reindex rather than update the index. Also, index updates can
> bloat the index.
|
|
> o ARRAY[[1,2],[3,4]])[1] should return the same values as
> ARRAY[[1,2],[3,4]])[1:1];
>
|
|
|
|
more, and standard_conforming_strings less, because in the future non-E
strings will not treat backslashes specially.
Also use E'' strings where backslashes are used in examples. (The
existing examples would have drawn warnings.)
Backpatch to 8.2.X.
|
|
|
|
|
|
< * Add Globally/Universally Unique Identifier (GUID/UUID)
> * -Add Globally/Universally Unique Identifier (GUID/UUID)
|
|
|
|
is now a target, no longer a modifier).
|
|
> * Enforce typmod for function inputs, function results and parameters for
> spi_prepare'd statements called from PLs
>
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg01403.php
|
|
> * Consider having the background writer update the transaction status
> hint bits before writing out the page
|
|
>
> * Consider increasing NUM_CLOG_BUFFERS
|
|
should not be done, per Peter.
|
|
version tag is 'devel'.
|
|
distinguish major vs minor release upgrades.
|
