unreserved according to the grammar.  The list of unreserved words has gotten
extensive enough that the unnecessary quoting is becoming a bit of an eyesore.
To do this, add knowledge of the keyword category to keywords.c's table.
(Someday we might be able to generate keywords.c's table and the keyword lists
in gram.y from a common source.)  For the moment, lie about WITH's status in
the table so it will still get quoted --- this is because of the expectation
that WITH will become reserved when the SQL recursive-queries patch gets done.

I didn't force initdb because this affects nothing on-disk; but note that a
few regression tests have changed expected output.

Simon Riggs

reads beyond EOF, except by special coercion.

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
<