profiling that CopyAttributeOutText was taking an unreasonable fraction of
the backend run time (like 66%!) on the following trivial test case:

$ time psql -c "copy (select repeat('xyzzy',50) from generate_series(1,10000000)) to stdout" regression >/dev/null

The time is all being spent on scanning the string for characters to be
escaped, which most of the time there aren't any of.  Some tweaking to take
as many tests as possible out of the inner loop reduced the runtime of this
example by more than 10%.  In a real-world case it wouldn't be as useful
a speedup, but it still seems worth adding a few lines here.

few lines in sql_exec_error_callback() by using the function source string
field that the patch added to SQL function cache entries.  This doesn't work
because the fn_extra field isn't filled in yet during init_sql_fcache().
Probably it could be made to work, but it doesn't seem appropriate to contort
the main code paths to make an error-reporting path a tad faster.  Per report
from Pavel Stehule.

an array of strings rather than an array of integers, and allow any simple
constant or identifier to be used in typmods; for example
	create table foo (f1 widget(42,'23skidoo',point));
Of course the typmodin function has still got to pack this info into a
non-negative int32 for storage, but it's still a useful improvement in
flexibility, especially considering that you can do nearly anything if you
are willing to keep the info in a side table.  We can get away with this
change since we have not yet released a version providing user-definable
typmods.  Per discussion.

to prevent possible deadlock problems.  Per request from Tom Lane.

options to deal with strange line endings.

reassembled in the syslogger before writing to the log file. This prevents
partial messages from being written, which mucks up log rotation, and
messages from different backends being interleaved, which causes garbled
logs. Backport as far as 8.0, where the syslogger was introduced.

Tom Lane and Andrew Dunstan

avoid mistakenly calling a function of the same name that might happen
to appear earlier in the schema search path.

< * 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.