Patch by Simon Riggs, per bug report from Ferenc Felhoffer

        /* This is PGC_SIGHUP so all backends have the same value. */

results always contribute two groups, regardless of the expression contents.
This is very substantially more accurate than the regular heuristic for
certain boolean tests like "col IS NULL".  Per gripe from Sam Mason.

Back-patch to all supported releases, since the behavior of
estimate_num_groups() hasn't changed all that much since 7.4.

the timezone argument as a timezone abbreviation, and only try it as a full
timezone name if that fails.  The zic database has four zones (CET, EET, MET,
WET) that are full daylight-savings zones and yet have names that are the
same as their abbreviations for standard time, resulting in ambiguity.
In the timestamp input functions we resolve the ambiguity by preferring the
abbreviation, and AT TIME ZONE should work the same way.  (No functionality
is lost because the zic database also has other names for these zones, eg
Europe/Zurich.)  Per gripe from Jaromir Talir.

Backpatch to 8.1.  Older releases did not have the issue because AT TIME ZONE
only accepted abbreviations not zone names.  (Thus, this patch also arguably
fixes a compatibility botch introduced at 8.1: in ambiguous cases we now
behave the same as 8.0 did.)

variable that has units.  Per report from Stefan Kaltenbrunner.

Backport to 8.2.  I also backported my patch of 2007-06-21 that prevented
comparable overflows on the input side, since that now seems to have enough
field track record to be back-patched safely.  That patch included addition
of hints listing the available unit names, which I did not bother to strip
out of it --- this will make a little more work for the translators, but
they can copy the translation from 8.3, and anyway an untranslated hint
is better than no hint.

* Don't cut off the prefix. With this fix, it's again readable.
* Properly store it in the Global namespace as intended.

known to the SQL parser.  Dave Page

scripts, to allow running the test successfully with another database name.

pains to pass the ERROR message components locally, including
using the passed SQLSTATE. Also wrap the passed info in an
appropriate CONTEXT message. Addresses complaint by Henry
Combrinck. Joe Conway, with much good advice from Tom Lane.

Guillaume Lelarge, with some additional fixes by me.

fix by Kris Jurka.

which are available if LOCK_DEBUG is defined.

* Add database and transaction-level triggers

> * Fix TRUNCATE ... RESTART IDENTITY so its affect on sequences is rolled
>   back on transaction abort

output for CREATE FUNCTION. This makes it easier to read especially if the
function body is long.

Original idea and patch by Greg Sabino Mullane, though this is a stripped
down version of that.

of different types than the underlying column. The capability isn't yet
used for anything, but will be required by upcoming patch to analyze
tsvector columns.

Jan Urbanski

one for client-side, restoring the previous behaviour with different
sort order for the 'log' level. Also, remove redundant list of available
options, since the enum code will output it automatically.

timezone setting in the current year and for 100 years back, rather than
always examining years 1904-2004.  The original coding would have problems
distinguishing zones whose behavior diverged only after 2004; which is a
situation we will surely face sometime, if it's not out there already.

In passing, also prevent selection of the dummy "Factory" timezone, even
if that's exactly what the system is using.  Reporting time as GMT seems
better than that.

backend.  If so, send a LOG message to the postmaster log, and if the table
is beyond the vacuum-for-wraparound horizon, forcibly drop it.  Per recent
discussions.  Perhaps we ought to back-patch this, but it probably needs
to age a bit in HEAD first.

observation by David Fetter.

values as postgresql.conf.

> 	o Add "auto" expanded mode that outputs in expanded format if
> 	  "wrapped" mode can't wrap the output to the screen width
>
> 	  http://archives.postgresql.org/pgsql-hackers/2008-05/msg00417.php
>

> 	o Add option to wrap column values at whitespace boundaries,
>           rather than chopping them at a fixed width.
> 	  Currently, "wrapped" format chops values into fixed
> 	  widths.  Perhaps the word wrapping could use the same
> 	  algorithm documented in the W3C specification.
> 	  http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php
> 	  http://www.w3.org/TR/CSS21/tables.html#auto-table-layout

laser <laserlist@pgsqldb.com> with some editorization by me.

As the buffer could now be a lot larger than before, and copying it could
thus be a lot more expensive than before, use strcpy instead of memcpy to
copy the query string, as was already suggested in comments. Also, only copy
the PgBackendStatus struct and string if the slot is in use.

Patch by Thomas Lee, with some changes by me.

space is tracked via GetMemoryChunkSpace, there's really no advantage
to duplicating datumCopy's innards here.  This is one bit of my toast
indirection patch that should go in anyway.

it ought to conform to the rest of palloc.h in using Size for sizes.

of any lower outer join, even if it also references the non-nullable side and
so could not get pushed below the outer join anyway.  We need this in case
the clause is an OR clause: if it doesn't get marked outerjoin_delayed,
create_or_index_quals() could pull an indexable restriction for the nullable
side out of it, leading to wrong results as demonstrated by today's bug
report from toruvinn.  (See added regression test case for an example.)

In principle this has been wrong for quite a while.  In practice I don't
think any branch before 8.3 can really show the failure, because
create_or_index_quals() will only pull out indexable conditions, and before
8.3 those were always strict.  So though we might have improperly generated
null-extended rows in the outer join, they'd get discarded from the result
anyway.  The gating factor that makes the failure visible is that 8.3
considers "col IS NULL" to be indexable.  Hence I'm not going to risk
back-patching further than 8.3.

Hiroshi Saito

taking the maximum of any child rel's width, we should weight the widths
proportionally to the number of rows expected from each child.  In hindsight
this is obviously correct because row width is really a proxy for the total
physical size of the relation.  Per discussion with Scott Carey (bug #4264).

values to libpq.

>
> * Fix system views like pg_stat_all_tables to use set-returning
>   functions, rather than views of per-column functions