Add some defenses against constant-FALSE outer join conditions.  Since
eval_const_expressions will generally throw away anything that's ANDed with
constant FALSE, what we're left with given an example like

select * from tenk1 a where (unique1,0) in (select unique2,1 from tenk1 b);

is a cartesian product computation, which is really not acceptable.
This is a regression in CVS HEAD compared to previous releases, which were
able to notice the impossible join condition in this case --- though not in
some related cases that are also improved by this patch, such as

select * from tenk1 a left join tenk1 b on (a.unique1=b.unique2 and 0=1);

Fix by skipping evaluation of the appropriate side of the outer join in
cases where it's demonstrably unnecessary.

Remove prohibition against SubLinks in the WHERE clause of an EXISTS subquery
that we're considering pulling up.  I hadn't wanted to think through whether
that could work during the first pass at this stuff.  However, on closer
inspection it seems to be safe enough.

Improve sublink pullup code to handle ANY/EXISTS sublinks that are at top
level of a JOIN/ON clause, not only at top level of WHERE.  (However, we
can't do this in an outer join's ON clause, unless the ANY/EXISTS refers
only to the nullable side of the outer join, so that it can effectively
be pushed down into the nullable side.)  Per request from Kevin Grittner.

In passing, fix a bug in the initial implementation of EXISTS pullup:
it would Assert if the EXIST's WHERE clause used a join alias variable.
Since we haven't yet flattened join aliases when this transformation
happens, it's necessary to include join relids in the computed set of
RHS relids.

Update instructions on generating TODO.html.

probes.h is generated from probes.d, not pg_trace.d.

Add URL for:

* Improve ability to modify views via ALTER TABLE
<
>   http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php

Fix pg_dump/pg_restore's ExecuteSqlCommand() to behave suitably if PQexec
returns NULL instead of a PGresult.  The former coding would fail, which
is OK, but it neglected to give you the PQerrorMessage that might tell
you why.  In the oldest branches, there was another problem: it'd sometimes
report PQerrorMessage from the wrong connection.

Add to TODO:

>
> * Prevent query cancel packets from being replayed by an attacker,
>   especially when using SSL
>
>   http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php
>

Synchronize Borland libpq makefile to match MSVC.  Backpatch to 8.3.X.

Fix a couple of places where psql might fail to report a suitable error
if PQexec returns NULL.  These don't seem significant enough to be worth
back-patching, but they ought to get fixed ...

Update Russian FAQ.

corochoone@gmail.com

Add new SQL training web site to FAQ:

    <LI><A href=
    "http://sqlzoo.net">http://sqlzoo.net</A>
    </LI>

Fix version warning bug in recently applied adjustments to psql startup.

Gregory Stark

Clean up the loose ends in selectivity estimation left by my patch for semi
and anti joins.  To do this, pass the SpecialJoinInfo struct for the current
join as an additional optional argument to operator join selectivity
estimation functions.  This allows the estimator to tell not only what kind
of join is being formed, but which variable is on which side of the join;
a requirement long recognized but not dealt with till now.  This also leaves
the door open for future improvements in the estimators, such as accounting
for the null-insertion effects of lower outer joins.  I didn't do anything
about that in the current patch but the information is in principle deducible
from what's passed.

The patch also clarifies the definition of join selectivity for semi/anti
joins: it's the fraction of the left input that has (at least one) match
in the right input.  This allows getting rid of some very fuzzy thinking
that I had committed in the original 7.4-era IN-optimization patch.
There's probably room to estimate this better than the present patch does,
but at least we know what to estimate.

Since I had to touch CREATE OPERATOR anyway to allow a variant signature
for join estimator functions, I took the opportunity to add a couple of
additional checks that were missing, per my recent message to -hackers:
* Check that estimator functions return float8;
* Require execute permission at the time of CREATE OPERATOR on the
operator's function as well as the estimator functions;
* Require ownership of any pre-existing operator that's modified by
the command.
I also moved the lookup of the functions out of OperatorCreate() and
into operatorcmds.c, since that seemed more consistent with most of
the other catalog object creation processes, eg CREATE TYPE.

Performance fix for new anti-join code in nodeMergejoin.c: after finding a
match in antijoin mode, we should advance to next outer tuple not next inner.
We know we don't want to return this outer tuple, and there is no point in
advancing over matching inner tuples now, because we'd just have to do it
again if the next outer tuple has the same merge key.  This makes a noticeable
difference if there are lots of duplicate keys in both inputs.

Similarly, after finding a match in semijoin mode, arrange to advance to
the next outer tuple after returning the current match; or immediately,
if it fails the extra quals.  The rationale is the same.  (This is a
performance bug in existing releases; perhaps worth back-patching?  The
planner tries to avoid using mergejoin with lots of duplicates, so it may
not be a big issue in practice.)

Nestloop and hash got this right to start with, but I made some cosmetic
adjustments there to make the corresponding bits of logic look more similar.

Make the temporary directory for pgstat files configurable by the GUC
variable stats_temp_directory, instead of requiring the admin to
mount/symlink the pg_stat_tmp directory manually.

For now the config variable is PGC_POSTMASTER. Room for further improvment
that would allow it to be changed on-the-fly.

Fix pull_up_simple_union_all to copy all rtable entries from child subquery to
parent, not only those with RangeTblRefs. We need them in ExecCheckRTPerms.

Report by Brendan O'Shea. Back-patch to 8.2, where pull_up_simple_union_all
was introduced.

Implement SEMI and ANTI joins in the planner and executor.  (Semijoins replace
the old JOIN_IN code, but antijoins are new functionality.)  Teach the planner
to convert appropriate EXISTS and NOT EXISTS subqueries into semi and anti
joins respectively.  Also, LEFT JOINs with suitable upper-level IS NULL
filters are recognized as being anti joins.  Unify the InClauseInfo and
OuterJoinInfo infrastructure into "SpecialJoinInfo".  With that change,
it becomes possible to associate a SpecialJoinInfo with every join attempt,
which permits some cleanup of join selectivity estimation.  That needs to be
taken much further than this patch does, but the next step is to change the
API for oprjoin selectivity functions, which seems like material for a
separate patch.  So for the moment the output size estimates for semi and
especially anti joins are quite bogus.

pg_buffercache needs to be taught about relation forks, as Greg Stark
pointed out.

Add URL for:

* Improve ability to modify views via ALTER TABLE

>   http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php

Have autovacuum consider processing TOAST tables separately from their
main tables.

This requires vacuum() to accept processing a toast table standalone, so
there's a user-visible change in that it's now possible (for a superuser) to
execute "VACUUM pg_toast.pg_toast_XXX".

Remove TODO item

    Allow XML to accept more liberal DOCTYPE specifications

Everything works correctly, per today's email to -general.

Add:

> * Add 'hostgss' pg_hba.conf option to allow GSS link-level encryption
>
>   http://archives.postgresql.org/pgsql-hackers/2008-07/msg01454.php

Relation forks patch requires a catversion bump due to changes in the format
of some WAL records, and two-phase state files, which I forgot.

Introduce the concept of relation forks. An smgr relation can now consist
of multiple forks, and each fork can be created and grown separately.

The bulk of this patch is about changing the smgr API to include an extra
ForkNumber argument in every smgr function. Also, smgrscheduleunlink and
smgrdounlink no longer implicitly call smgrclose, because other forks might
still exist after unlinking one. The callers of those functions have been
modified to call smgrclose instead.

This patch in itself doesn't have any user-visible effect, but provides the
infrastructure needed for upcoming patches. The additional forks envisioned
are a rewritten FSM implementation that doesn't rely on a fixed-size shared
memory block, and a visibility map to allow skipping portions of a table in
VACUUM that have no dead tuples.

Fix corner-case bug introduced with HOT: if REINDEX TABLE pg_class (or a
REINDEX DATABASE including same) is done before a session has done any other
update on pg_class, the pg_class relcache entry was left with an incorrect
setting of rd_indexattr, because the indexed-attributes set would be first
demanded at a time when we'd forced a partial list of indexes into the
pg_class entry, and it would remain cached after that.  This could result
in incorrect decisions about HOT-update safety later in the same session.
In practice, since only pg_class_relname_nsp_index would be missed out,
only ALTER TABLE RENAME and ALTER TABLE SET SCHEMA could trigger a problem.
Per report and test case from Ondrej Jirman.

Install checks in executor startup to ensure that the tuples produced by an
INSERT or UPDATE will match the target table's current rowtype.  In pre-8.3
releases inconsistency can arise with stale cached plans, as reported by
Merlin Moncure.  (We patched the equivalent hazard on the SELECT side in Feb
2007; I'm not sure why we thought there was no risk on the insertion side.)
In 8.3 and HEAD this problem should be impossible due to plan cache
invalidation management, but it seems prudent to make the check anyway.

Back-patch as far as 8.0.  7.x versions lack ALTER COLUMN TYPE, so there
seems no way to abuse a stale plan comparably.

Improve INTERSECT/EXCEPT hashing by realizing that we don't need to make any
hashtable entries for tuples that are found only in the second input: they
can never contribute to the output.  Furthermore, this implies that the
planner should endeavor to put first the smaller (in number of groups) input
relation for an INTERSECT.  Implement that, and upgrade prepunion's estimation
of the number of rows returned by setops so that there's some amount of sanity
in the estimate of which one is smaller.

Support hashing for duplicate-elimination in INTERSECT and EXCEPT queries.
This completes my project of improving usage of hashing for duplicate
elimination (aggregate functions with DISTINCT remain undone, but that's
for some other day).

As with the previous patches, this means we can INTERSECT/EXCEPT on datatypes
that can hash but not sort, and it means that INTERSECT/EXCEPT without ORDER
BY are no longer certain to produce sorted output.

Teach the system how to use hashing for UNION.  (INTERSECT/EXCEPT will follow,
but seem like a separate patch since most of the remaining work is on the
executor side.)  I took the opportunity to push selection of the grouping
operators for set operations into the parser where it belongs.  Otherwise this
is just a small exercise in making prepunion.c consider both alternatives.

As with the recent DISTINCT patch, this means we can UNION on datatypes that
can hash but not sort, and it means that UNION without ORDER BY is no longer
certain to produce sorted output.

Do not allow Unique nodes to be scanned backwards.  The code claimed that it
would work, but in fact it didn't return the same rows when moving backwards
as when moving forwards.  This would have no visible effect in a DISTINCT
query (at least assuming the column datatypes use a strong definition of
equality), but it gave entirely wrong answers for DISTINCT ON queries.

Department of second thoughts: fix newly-added code in planner.c to make real
sure that DISTINCT ON does what it's supposed to, ie, sort by the full ORDER
BY list before unique-ifying.  The error seems masked in simple cases by the
fact that query_planner won't return query pathkeys that only partially match
the requested sort order, but I wouldn't want to bet that it couldn't be
exposed in some way or other.

Add an ORDER BY to one more SELECT DISTINCT test case, per buildfarm results.

In ReadOrZeroBuffer (and related entry points), don't bother to call
PageHeaderIsValid when we zero the buffer instead of reading the page in.
The actual performance improvement is probably marginal since this function
isn't very heavily used, but a cycle saved is a cycle earned.

Zdenek Kotala

Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp.
This allows the use of a ramdrive (either through mount or symlink) for
the temporary file that's written every half second, which should
reduce I/O.

On server shutdown/startup, the file is written to the old location in
the global directory, to preserve data across restarts.

Bump catversion since the $PGDATA directory layout changed.

Fix some message style guideline violations in pg_regress, as well as
some failures to expose messages for translation.

Improve SELECT DISTINCT to consider hash aggregation, as well as sort/uniq,
as methods for implementing the DISTINCT step.  This eliminates the former
performance gap between DISTINCT and GROUP BY, and also makes it possible
to do SELECT DISTINCT on datatypes that only support hashing not sorting.

SELECT DISTINCT ON is still always implemented by sorting; it would take
executor changes to support hashing that, and it's not clear it's worth
the trouble.

This is a release-note-worthy incompatibility from previous PG versions,
since SELECT DISTINCT can no longer be counted on to deliver sorted output
without explicitly saying ORDER BY.  (Anyone who can't cope with that
can consider turning off enable_hashagg.)

Several regression test queries needed to have ORDER BY added to preserve
stable output order.  I fixed the ones that manifested here, but there
might be some other cases that show up on other platforms.

Improve CREATE/DROP/RENAME DATABASE so that when failing because the source
or target database is being accessed by other users, it tells you whether
the "other users" are live sessions or uncommitted prepared transactions.
(Indeed, it tells you exactly how many of each, but that's mostly just
because it was easy to do so.)  This should help forestall the gotcha of
not realizing that a prepared transaction is what's blocking the command.
Per discussion.

Make GROUP BY work properly for datatypes that only support hashing and not
sorting.  The infrastructure for this was all in place already; it's only
necessary to fix the planner to not assume that sorting is always an available
option.

Tighten up the sanity checks in TypeCreate(): pass-by-value types must have
a size that is one of the supported values, not just anything <= sizeof(Datum).
Cross-check the alignment specification against size as well.

Fix copy-and-pasteo that's causing pg_regress to lie about which file it can't
read when the --temp-config argument is bad.  Noted while wondering why
buildfarm member dungbeetle is failing ... this isn't why, but it is why
the error report isn't very helpful ...

Rearrange the querytree representation of ORDER BY/GROUP BY/DISTINCT items
as per my recent proposal:

1. Fold SortClause and GroupClause into a single node type SortGroupClause.
We were already relying on them to be struct-equivalent, so using two node
tags wasn't accomplishing much except to get in the way of comparing items
with equal().

2. Add an "eqop" field to SortGroupClause to carry the associated equality
operator.  This is cheap for the parser to get at the same time it's looking
up the sort operator, and storing it eliminates the need for repeated
not-so-cheap lookups during planning.  In future this will also let us
represent GROUP/DISTINCT operations on datatypes that have hash opclasses
but no btree opclasses (ie, they have equality but no natural sort order).
The previous representation simply didn't work for that, since its only
indicator of comparison semantics was a sort operator.

3. Add a hasDistinctOn boolean to struct Query to explicitly record whether
the distinctClause came from DISTINCT or DISTINCT ON.  This allows removing
some complicated and not 100% bulletproof code that attempted to figure
that out from the distinctClause alone.

This patch doesn't in itself create any new capability, but it's necessary
infrastructure for future attempts to use hash-based grouping for DISTINCT
and UNION/INTERSECT/EXCEPT.

Cope with Tcl versions that do not create a tclsh symlink to the version-
numbered program.  Per persistent buildfarm failures.

Tom Lane

Add a few more DTrace probes to the backend.

Robert Lor

Rearrange the code in auth.c so that all functions for a single authentication
method is grouped together in a reasonably similar way, keeping the "global
shared functions" together in their own section as well. Makes it a lot easier
to find your way around the code.

Move ident authentication code into auth.c along with the other authenciation
routines, leaving hba.c to deal only with processing the HBA specific files.

Fix parser so that we don't modify the user-written ORDER BY list in order
to represent DISTINCT or DISTINCT ON.  This gets rid of a longstanding
annoyance that a view or rule using SELECT DISTINCT will be dumped out
with an overspecified ORDER BY list, and is one small step along the way
to decoupling DISTINCT and ORDER BY enough so that hash-based implementation
of DISTINCT will be possible.  In passing, improve transformDistinctClause
so that it doesn't reject duplicate DISTINCT ON items, as was reported by
Steve Midgley a couple weeks ago.

Add URL to:

* Consider decreasing the I/O caused by updating tuple hint bits

>   http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php

Require superuser privilege to create base types (but not composites, enums,
or domains).  This was already effectively required because you had to own
the I/O functions, and the I/O functions pretty much have to be written in
C since we don't let PL functions take or return cstring.  But given the
possible security consequences of a malicious type definition, it seems
prudent to enforce superuser requirement directly.  Per recent discussion.

Allow I/O conversion casts to be applied to or from any type that is a member
of the STRING type category, thereby opening up the mechanism for user-defined
types.  This is mainly for the benefit of citext, though; there aren't likely
to be a lot of types that are all general-purpose character strings.
Per discussion with David Wheeler.

Flip the default typispreferred setting from true to false.  This affects
only type categories in which the previous coding made *every* type
preferred; so there is no change in effective behavior, because the function
resolution rules only do something different when faced with a choice
between preferred and non-preferred types in the same category.  It just
seems safer and less surprising to have CREATE TYPE default to non-preferred
status ...

Adjust citext to make use of the new ability to declare its type category:
by putting it into the standard string category, we cause casts from citext
to text to be recognized as "preferred" casts.  This eliminates the need
for creation of alias functions and operators that only serve to prevent
ambiguous-function errors; get rid of the ones that were in the original
commit.

Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation.  Instead put the information into two new pg_type columns,
typcategory and typispreferred.  Add support for setting these when
creating a user-defined base type.

The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character.  This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.

In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums.  In particular the default preferred state
for user-defined types remains TRUE.  That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.

Add a new, improved version of citext as a contrib module.

David E. Wheeler

Cleanup reference to config.pl so it makes sense not only in
SGML source but in the actual web/pdf viewer...

Document which versions of ActivePerl and ActiveTcl are required
for building on MSVC, and that the free distribution is enough
(no need for the enterprise version).

Per gripe from Martin Zaun.

As noted by Andrew Gierth, there's really no need any more to force a junk
filter to be used when INSERT or SELECT INTO has a plan that returns raw
disk tuples.  The virtual-tuple-slot optimizations that were put in place
awhile ago mean that ExecInsert has to do ExecMaterializeSlot, and that
already copies the tuple if it's raw (and does so more efficiently than
a junk filter, too).  So get rid of that logic.  This in turn means that
we can throw away ExecMayReturnRawTuples, which wasn't used for any other
purpose, and was always a kluge anyway.

In passing, move a couple of SELECT-INTO-specific fields out of EState
and into the private state of the SELECT INTO DestReceiver, as was foreseen
in an old comment there.  Also make intorel_receive use ExecMaterializeSlot
not ExecCopySlotTuple, for consistency with ExecInsert and to possibly save
a tuple copy step in some cases.

Fix parsing of LDAP URLs so it doesn't reject spaces in the "suffix" part.
Per report from César Miguel Oliveira Alves.

Remove some redundant tests and improve comments in next_token().
Cosmetic, but it might make this a bit less confusing to the next reader.

Ratchet up patch to improve autovacuum wraparound messages.

Simon Riggs

Use guc.c's parse_int() instead of pg_atoi() to parse fillfactor in
default_reloptions().  The previous coding was really a bug because pg_atoi()
will always throw elog on bad input data, whereas default_reloptions is not
supposed to complain about bad input unless its validate parameter is true.
Right now you could only expose the problem by hand-modifying
pg_class.reloptions into an invalid state, so it doesn't seem worth
back-patching; but we should get it right in HEAD because there might be other
situations in future.  Noted while studying GIN fast-update patch.

Abort if Tcl support was configured and no tcl shell was found.
This is required because the value is substituted into the pltcl_*mod
scripts.

Update link to Oleg and Teodor's GIN page.
(Extracted from fast-insert patch, since it ought to be back-patched)

Publish more openly the fact that autovacuum is working for wraparound
protection.

Simon Riggs

Add comment about the two different query strings that ExecuteQuery()
has to deal with.

Code review for array_fill patch: fix inadequate check for array size overflow
and bogus documentation (dimension arrays are int[] not anyarray).  Also the
errhint() messages seem to be really errdetail(), since there is nothing
heuristic about them.  Some other trivial cosmetic improvements.

Add a pg_dump option --lock-wait-timeout to allow failing the dump if unable
to acquire shared table locks within a specified amount of time.

David Gould

Revert patch so .psqlrc can suppress startup banner:

  In psql, run .psqlrc _after_ printing warnings and banner.

Avoid substituting NAMEDATALEN, FLOAT4PASSBYVAL, and FLOAT8PASSBYVAL into
the postgres.bki file during build, because we want that file to be entirely
platform- and configuration-independent; else it can't safely be put into
/usr/share on multiarch machines.  We can do the substitution during initdb,
instead.  FLOAT4PASSBYVAL and FLOAT8PASSBYVAL are new breakage as of 8.4,
while the NAMEDATALEN hazard has been there all along but I guess no one
tripped over it.  Noticed while trying to build "universal" OS X binaries.

Adjust things so that the query_string of a cached plan and the sourceText of
a portal are never NULL, but reliably provide the source text of the query.
It turns out that there was only one place that was really taking a short-cut,
which was the 'EXECUTE' utility statement.  That doesn't seem like a
sufficiently critical performance hotspot to justify not offering a guarantee
of validity of the portal source text.  Fix it to copy the source text over
from the cached plan.  Add Asserts in the places that set up cached plans and
portals to reject null source strings, and simplify a bunch of places that
formerly needed to guard against nulls.

There may be a few places that cons up statements for execution without
having any source text at all; I found one such in ConvertTriggerToFK().
It seems sufficient to inject a phony source string in such a case,
for instance
        ProcessUtility((Node *) atstmt,
                       "(generated ALTER TABLE ADD FOREIGN KEY command)",
                       NULL, false, None_Receiver, NULL);

We should take a second look at the usage of debug_query_string,
particularly the recently added current_query() SQL function.

ITAGAKI Takahiro and Tom Lane

Provide a function hook to let plug-ins get control around ExecutorRun.

ITAGAKI Takahiro

Properly document archive/restore command examples on Windows.

ITAGAKI Takahiro

In psql, run .psqlrc _after_ printing warnings and banner.

Fix a race condition that I introduced into sinvaladt.c during the recent
rewrite.  When called from SIInsertDataEntries, SICleanupQueue releases
the write lock if it has to issue a kill() to signal some laggard backend.
That still seems like a good idea --- but it's possible that by the time
we get the lock back, there are no longer enough free message slots to
satisfy SIInsertDataEntries' requirement.  Must recheck, and repeat the
whole SICleanupQueue process if not.  Noted while reading code.

Suppress compiler warning, and not incidentally make the code more
robust.  The previous coding was quite risky because it was testing
conditions different from 'is the array really allocated?'.

Implement SQL-spec RETURNS TABLE syntax for functions.

(Unlike the original submission, this patch treats TABLE output parameters
as being entirely equivalent to OUT parameters -- tgl)

Pavel Stehule

Add URL for:

* Implement SQL:2003 window functions

>   http://archives.postgresql.org/pgsql-hackers/2008-07/msg00232.php

Add MSVC++ debug libraries to .cvsignore.

Avoid crashing when a table is deleted while we're on the process of checking
it.

Per report from Tom Lane based on buildfarm evidence.

Add dump support for SortBy nodes.  Needed this while debugging a reported
problem with DISTINCT, so might as well commit it.

Add to TODO:
>
> * Reduce locking requirements for creating a trigger
>
>   http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php
>

Add URL for:

* Implement SQL:2003 window functions
>
>   http://archives.postgresql.org/pgsql-hackers/2008-06/msg00380.php
>

Fix previous patch so that it actually works --- consider TRUNCATE foo, public.foo

Add a "provariadic" column to pg_proc to eliminate the remarkably expensive
need to deconstruct proargmodes for each pg_proc entry inspected by
FuncnameGetCandidates().  Fixes function lookup performance regression
caused by yesterday's variadic-functions patch.

In passing, make pg_proc.probin be NULL, rather than a dummy value '-',
in cases where it is not actually used for the particular type of function.
This should buy back some of the space cost of the extra column.

Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

Add to TODO:

>
>  o Add external tool to auto-tune some postgresql.conf parameters
>
>    http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php
>

Support "variadic" functions, which can accept a variable number of arguments
so long as all the trailing arguments are of the same (non-array) type.
The function receives them as a single array argument (which is why they
have to all be the same type).

It might be useful to extend this facility to aggregates, but this patch
doesn't do that.

This patch imposes a noticeable slowdown on function lookup --- a follow-on
patch will fix that by adding a redundant column to pg_proc.

Pavel Stehule

Add array_fill() to create arrays initialized with a value.

Pavel Stehule

Fix alignment of SGML array docs.

Add Swedish_Sweden.1252 Windows locale example to docs.

Addendum:  psql sequence value display patch was originally written by
Euler Taveira de Oliveira.

Add to TODO:

>
>  o Reduce PITR WAL file size by removing full page writes and
>    by removing trailing bytes to improve compression

Add TODO:

>
> * Consider decreasing the I/O caused by updating tuple hint bits
>
>   http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php
>

Done:

>  o -Have psql show current values for a sequence

Have psql \d show the value of sequence columns.

Dickson S. Guedes

Clarify that locale names on Windows are more verbose.

Report from Martin Saschek

Add comment about literal strings in our syntax not being translated in
psql.

Add to TODO:

> * Improve ability to modify views via ALTER TABLE
>
>   http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php

Add column storage type to psql \d+ display.

Gregory Stark

In psql, rename trans_* variables to translate_*, for clarity.