David E. Wheeler

SGML source but in the actual web/pdf viewer...

for building on MSVC, and that the free distribution is enough
(no need for the enterprise version).

Per gripe from Martin Zaun.

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.

Per report from César Miguel Oliveira Alves.

Cosmetic, but it might make this a bit less confusing to the next reader.

Simon Riggs

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.

This is required because the value is substituted into the pltcl_*mod
scripts.

(Extracted from fast-insert patch, since it ought to be back-patched)

protection.

Simon Riggs

has to deal with.

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.

to acquire shared table locks within a specified amount of time.

David Gould

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

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.

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

ITAGAKI Takahiro

ITAGAKI Takahiro

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.

robust.  The previous coding was quite risky because it was testing
conditions different from 'is the array really allocated?'.

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

Pavel Stehule

* Implement SQL:2003 window functions

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

it.

Per report from Tom Lane based on buildfarm evidence.

problem with DISTINCT, so might as well commit it.

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

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

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.

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

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

Pavel Stehule

Euler Taveira de Oliveira.

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

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