< * Allow EXPLAIN output to be more easily processed by scripts
> * Allow EXPLAIN output to be more easily processed by scripts, perhaps XML

comments noting that there's an alignment assumption now that the data
field could be in 1-byte-header format.  Per discussion with Greg Stark.

Add ability to add "prefix include directories", and use it...

With this, ecpg regression tests now pass on MSVC builds.

the normal heap_getattr() machinery.  Per Greg Stark.

historically worked in some but not all cases, but as of 8.2 it failed for all
timezone formats.  Fix, and add regression test cases to catch future
regressions in this area.  Per gripe from Adam Witney.

Fixes buildfarm failures on contribcheck.

regression driver into two parts and reusing half of it. Required to
run ECPG tests without a shell on MSVC builds.

Fix ECPG thread tests for MSVC build (incl output files).

Joachim Wieland and Magnus Hagander

with a plpgsql-defined cursor.  The underlying mechanism for this is that the
main SQL engine will now take "WHERE CURRENT OF $n" where $n is a refcursor
parameter.  Not sure if we should document that fact or consider it an
implementation detail.  Per discussion with Pavel Stehule.

Made sure ecpg deletes output file in case of an error.

< 	o Allow UPDATE/DELETE WHERE CURRENT OF cursor
<
< 	  This requires using the row ctid to map cursor rows back to the
< 	  original heap row. This become more complicated if WITH HOLD cursors
< 	  are to be supported because WITH HOLD cursors have a copy of the row
< 	  and no FOR UPDATE lock.
< 	  http://archives.postgresql.org/pgsql-hackers/2007-01/msg01014.php
<
> 	o -Allow UPDATE/DELETE WHERE CURRENT OF cursor

Along the way, allow FOR UPDATE in non-WITH-HOLD cursors; there may once
have been a reason to disallow that, but it seems to work now, and it's
really rather necessary if you want to select a row via a cursor and then
update it in a concurrent-safe fashion.

Original patch by Arul Shaji, rather heavily editorialized by Tom Lane.

pseudo HeapScanDesc created for a bitmap heap scan.  This avoids some useless
overhead during a bitmap scan startup, in particular invoking the syncscan
code.  (We might someday want to do that, but right now it's merely useless
contention for shared memory, to say nothing of possibly pushing useful
entries out of syncscan's small LRU list.)  This also allows elimination of
ugly pgstat_discount_heap_scan() kluge.

results due to syncscan patch, when shared_buffers is small enough.  Per
buildfarm reports and some local testing with shared_buffers set to the
lowest value considered by initdb.

large inputs.  Also cause it to error out immediately if the result will
overflow, instead of grinding through a lot of calculation first.
Per gripe from Jim Nasby.

causes a division-by-zero error in the vacuum code.  This can happen when there
are more workers than cost limit units.

Per report from Galy Lee in
<200705310914.l4V9E6JA094603@wwwmaster.postgresql.org>.

value for the vacuum code.  Instead, make zero signify getting the value from a
higher level configuration facility, just like -1 in the original coding.  We
still document that -1 is the value that disables the feature, to avoid
confusing the user unnecessarily.

Reported by Galy Lee in <200705310914.l4V9E6JA094603@wwwmaster.postgresql.org>;
per subsequent discussion.

results.  Necessary due to introduction of syncscan patch.

< * Allow sequential scans to take advantage of other concurrent
> * -Allow sequential scans to take advantage of other concurrent
<
<   One possible implementation is to start sequential scans from the lowest
<   numbered buffer in the shared cache, and when reaching the end wrap
<   around to the beginning, rather than always starting sequential scans
<   at the start of the table.
<
<   http://archives.postgresql.org/pgsql-patches/2006-12/msg00076.php
<   http://archives.postgresql.org/pgsql-hackers/2006-12/msg00408.php
<   http://archives.postgresql.org/pgsql-hackers/2006-12/msg00784.php
<   http://archives.postgresql.org/pgsql-hackers/2007-03/msg00415.php
<

when multiple backends are scanning the same relation concurrently, each page
is (ideally) read only once.

Jeff Davis, with review by Heikki and Tom.

which is the only state in which it's safe to initiate database queries.
It turns out that all but two of the callers thought that's what it meant;
and the other two were using it as a proxy for "will GetTopTransactionId()
return a nonzero XID"?  Since it was in fact an unreliable guide to that,
make those two just invoke GetTopTransactionId() always, then deal with a
zero result if they get one.

for each temp file, rather than once per sort or hashjoin; this allows
spreading the data of a large sort or join across multiple tablespaces.
(I remain dubious that this will make any difference in practice, but certain
people insisted.)  Arrange to cache the results of parsing the GUC variable
instead of recomputing from scratch on every demand, and push usage of the
cache down to the bottommost fd.c level.

Fuhr, patch from Tom Lane after a messier suggestion by me.

Christian Rossow

from contrib/pgstattuple to pageinspect. We've already fixed English
documentation, but Japanese version does not catch up.

ITAGAKI Takahiro

were accepted by prior Postgres releases.  This takes care of the loose end
left by the preceding patch to downgrade implicit casts-to-text.  To avoid
breaking desirable behavior for array concatenation, introduce a new
polymorphic pseudo-type "anynonarray" --- the added concatenation operators
are actually text || anynonarray and anynonarray || text.

from the other string-category types; this eliminates a lot of surprising
interpretations that the parser could formerly make when there was no directly
applicable operator.

Create a general mechanism that supports casts to and from the standard string
types (text,varchar,bpchar) for *every* datatype, by invoking the datatype's
I/O functions.  These new casts are assignment-only in the to-string direction,
explicit-only in the other, and therefore should create no surprising behavior.
Remove a bunch of thereby-obsoleted datatype-specific casting functions.

The "general mechanism" is a new expression node type CoerceViaIO that can
actually convert between *any* two datatypes if their external text
representations are compatible.  This is more general than needed for the
immediate feature, but might be useful in plpgsql or other places in future.

This commit does nothing about the issue that applying the concatenation
operator || to non-text types will now fail, often with strange error messages
due to misinterpreting the operator as array concatenation.  Since it often
(not always) worked before, we should either make it succeed or at least give
a more user-friendly error; but details are still under debate.

Peter Eisentraut and Tom Lane

a session regardless of the existence of cached plans. The plancache
only needs to be invalidated so that rules affected by the new setting
will be reflected in the new query plans.

Jan

Many thanks to Heikki Linnakangas <heikki@enterprisedb.com> for his
sharp eyes.