Do not allow Unique nodes to be scanned backwards.  The code claimed that it
would work, but in fact it didn't return the same rows when moving backwards
as when moving forwards.  This would have no visible effect in a DISTINCT
query (at least assuming the column datatypes use a strong definition of
equality), but it gave entirely wrong answers for DISTINCT ON queries.

Fix parsing of LDAP URLs so it doesn't reject spaces in the "suffix" part.
Per report from César Miguel Oliveira Alves.

Update link to Oleg and Teodor's GIN page.
(Extracted from fast-insert patch, since it ought to be back-patched)

Fix an oversight in the original implementation of performMultipleDeletions():
the alreadyDeleted list has to be passed down through
deleteDependentObjects(), else objects that are deleted via auto/internal
dependencies don't get reported back up to performMultipleDeletions().
Depending on the visitation order, this could cause the code to try to delete
an already-deleted object, leading to strange errors in DROP OWNED (typically
"cache lookup failed for relation NNNNN" or similar).  Per bug #4289.

Patch for back branches only.  This code has recently been rewritten in HEAD,
and doesn't have this particular bug anymore.

Fix mis-calculation of extParam/allParam sets for plan nodes, as seen in
bug #4290.  The fundamental bug is that masking extParam by outer_params,
as finalize_plan had been doing, caused us to lose the information that
an initPlan depended on the output of a sibling initPlan.  On reflection
the best thing to do seemed to be not to try to adjust outer_params for
this case but get rid of it entirely.  The only thing it was really doing
for us was to filter out param IDs associated with SubPlan nodes, and that
can be done (with greater accuracy) while processing individual SubPlan
nodes in finalize_primnode.  This approach was vindicated by the discovery
that the masking method was hiding a second bug: SS_finalize_plan failed to
remove extParam bits for initPlan output params that were referenced in the
main plan tree (it only got rid of those referenced by other initPlans).
It's not clear that this caused any real problems, given the limited use
of extParam by the executor, but it's certainly not what was intended.

I originally thought that there was also a problem with needing to include
indirect dependencies on external params in initPlans' param sets, but it
turns out that the executor handles this correctly so long as the depended-on
initPlan is earlier in the initPlans list than the one using its output.
That seems a bit of a fragile assumption, but it is true at the moment,
so I just documented it in some code comments rather than making what would
be rather invasive changes to remove the assumption.

Back-patch to 8.1.  Previous versions don't have the case of initPlans
referring to other initPlans' outputs, so while the existing logic is still
questionable for them, there are not any known bugs to be fixed.  So I'll
refrain from changing them for now.

Fix performance bug in write_syslog(): the code to preferentially break the
log message at newlines cost O(N^2) for very long messages with few or no
newlines.  For messages in the megabyte range this became the dominant cost.
Per gripe from Achilleas Mantzios.

Patch all the way back, since this is a safe change with no portability
risks.  I am also thinking of increasing PG_SYSLOG_LIMIT, but that should
be done separately.

Fix estimate_num_groups() to assume that GROUP BY expressions yielding boolean
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.

Fix AT TIME ZONE (in all three variants) so that we first try to interpret
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.)

Prevent integer overflows during units conversion when displaying a GUC
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.

Fix identify_system_timezone() so that it tests the behavior of the system
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.

Fix 'pg_ctl reload' to properly preserve postmaster commend-line
arguments on restart.  Patch to releases 8.0 - 8.3.X.

Clean up a number of bogosities around pltcl's handling of the Tcl "result":

1. Directly reading interp->result is deprecated in Tcl 8.0 and later;
you're supposed to use Tcl_GetStringResult.  This code finally broke with
Tcl 8.5, because Tcl_GetVar can now have side-effects on interp->result even
though it preserves the logical state of the result.  (There's arguably a
Tcl issue here, because Tcl_GetVar could invalidate the pointer result of a
just-preceding Tcl_GetStringResult, but I doubt the Tcl guys will see it as
a bug.)

2. We were being sloppy about the encoding of the result: some places would
push database-encoding data into the Tcl result, which should not happen,
and we were assuming that any error result coming back from Tcl was in the
database encoding, which is not a good assumption.

3. There were a lot of calls of Tcl_SetResult that uselessly specified
TCL_VOLATILE for constant strings.  This is only a minor performance issue,
but I fixed it in passing since I had to look at all the calls anyway.

#2 is a live bug regardless of which Tcl version you are interested in,
so back-patch even to branches that are unlikely to be used with Tcl 8.5.
I went back as far as 8.0, which is as far as the patch applied easily;
7.4 was using a different error processing scheme that has got its own
problems :-(

Fix bug in the WAL recovery code to finish an incomplete split.
CacheInvalidateRelcache() crashes if called in WAL recovery, because the
invalidation infrastructure hasn't been initialized yet.

Back-patch to 8.2, where the bug was introduced.

Create a script to handle stamping release version numbers into files,
replacing the tedious and error-prone manual process we've been using.

Fix datetime input functions to correctly detect integer overflow when
running on a 64-bit platform ... strtol() will happily return 64-bit
output in that case.  Per bug #4231 from Geoff Tolley.

tag 8.2.9

Stamp 8.2.9 (except for configure.in/configure)

Update release notes for ALTER AGGREGATE fix.

ALTER AGGREGATE OWNER seems to have been missed by the last couple of
patches that dealt with object ownership.  It wasn't updating pg_shdepend
nor adjusting the aggregate's ACL.  In 8.2 and up, fix this permanently
by making it use AlterFunctionOwner_oid.  In 8.1, the function code wasn't
factored that way, so just copy and paste.

Update release notes for 8.3.3 et al.

Fix pg_get_ruledef() so that negative numeric constants are parenthesized.
This is needed because :: casting binds more tightly than minus, so for
example -1::integer is not the same as (-1)::integer, and there are cases
where the difference is important.  In particular this caused a failure
in SELECT DISTINCT ... ORDER BY ... where expressions that should have
matched were seen as different by the parser; but I suspect that there
could be other cases where failure to parenthesize leads to subtler
semantic differences in reloaded rules.  Per report from Alexandr Popov.

tag 8.2.8

Stamp 8.2.8 (except for configure.in/configure)

Translation updates.

Added SQL to list of allowed variable names.

Draft release notes for upcoming back-branch updates.

Update time zone data files to tzdata release 2008c (DST law changes in
Morocco, Iraq, Choibalsan, Pakistan, Syria, Cuba, Argentina/San_Luis).

Fix some bugs introduced by the 8.2-era conversion of cube functions to V1
calling convention.  cube_inter and cube_distance could attempt to pfree
their input arguments, and cube_dim returned a value from a struct it
might have just pfree'd (which would only really cause a problem in a
debug build, but it's still wrong).  Per bug #4208 and additional code
reading.

In HEAD and 8.3, I also made a batch of cosmetic changes to bring these
functions into line with the preferred coding style for V1 functions,
ie declare and fetch all the arguments at the top so readers can easily
see what they are.

Update odbc URL.

Backpatch Zdenek Kotala's fix to prevent pglz_decompress from stomping on
memory if the compressed data is corrupt.

Backpatch as far as 8.2.  The issue exists in older branches too, but given
the lack of field reports, it's not clear it's worth any additional effort
to adapt the patch to the slightly different code in older branches.

Improve GRANT documentation to point out that UPDATE and DELETE typically
require SELECT privilege as well, since you normally need to read existing
column values within such commands.  This behavior is according to spec,
but we'd never documented it before.  Per gripe from Volkan Yazici.

Require bind_textdomain_codeset() not just gettext() to enable NLS support.
GNU gettext before 0.10.36 does not have that function, and is generally too
incomplete to be usable.

Back-patch the 8.3 fix that prohibits TRUNCATE, CLUSTER, and REINDEX when the
current transaction has any open references to the target relation or index
(implying it has an active query using the relation).  Also back-patch the
8.2 fix that prohibits TRUNCATE and CLUSTER when there are pending
AFTER-trigger events.  Per suggestion from Heikki.

Explicitly bind gettext() to the  UTF8 locale when in use.
This is required on Windows due to the special locale
handling for UTF8 that doesn't change the full environment.

Fixes crash with translated error messages per bugs 4180
and 4196.

Tom Lane

Fix an old corner-case bug in set_config_option: push_old_value has to be
called before, not after, calling the assign_hook if any.  This is because
push_old_value might fail (due to palloc out-of-memory), and in that case
there would be no stack entry to tell transaction abort to undo the GUC
assignment.  Of course the actual assignment to the GUC variable hasn't
happened yet --- but the assign_hook might have altered subsidiary state.
Without a stack entry we won't call it again to make it undo such actions.
So this is necessary to make the world safe for assign_hooks with side
effects.  Per a discussion a couple weeks ago with Magnus.

Back-patch to 8.0.  7.x did not have the problem because it did not have
allocatable stacks of GUC values.

Adjust timestamp regression tests to prevent two low-probability failure
cases.  Recent buildfarm experience shows that it is sometimes possible
to execute several SQL commands in less time than the granularity of
Windows' not-very-high-resolution gettimeofday(), leading to a failure
because the tests expect the value of now() to change and it doesn't.
Also, it was recognized some time ago that the same area of the tests
could fail if local midnight passes between the insertion and the checking
of the values for 'yesterday', 'tomorrow', etc.  Clean all this up per
ideas from myself and Greg Stark.

There remains a window for failure if the transaction block is entered
exactly at local midnight (so that 'now' and 'today' have the same value),
but that seems low-probability enough to live with.

Since the point of this change is mostly to eliminate buildfarm noise,
back-patch to all versions we are still actively testing.

Remove arbitrary 10MB limit on two-phase state file size. It's not that hard
to go beoynd 10MB, as demonstrated by Gavin Sharry's example of dropping a
schema with ~25000 objects. The really bogus thing about the limit was that
it was enforced when a state file file was read in, not when it was written,
so you would end up with a prepared transaction that you can't commit or
abort, and the only recourse was to shut down the server and remove the file
by hand.

Raise the limit to MaxAllocSize, and enforce it also when a state file is
written. We could've removed the limit altogether, but reading in a file
larger than MaxAllocSize would fail anyway because we read it into a
palloc'd buffer.

Backpatch down to 8.1, where 2PC and this issue was introduced.

Don't try to close negative file descriptors, since this can cause
crashes on certain platforms. In particular, the MSVC runtime is known
to do this.

Fixes bug #4162, reported and diagnosed by Javier Pimas

Fix an ancient oversight in change_varattnos_of_a_node: it neglected to update
varoattno along with varattno.  This resulted in having Vars that were not
seen as equal(), causing inheritance of the "same" constraint from different
parent relations to fail.  An example is

create table pp1 (f1 int check (f1>0));
create table cc1 (f2 text, f3 int) inherits (pp1);
create table cc2(f4 float) inherits(pp1,cc1);

Backpatch as far as 7.4.  (The test case still fails in 7.4, for reasons
that I don't feel like investigating at the moment.)

This is a backpatch commit only.  The fix will be applied in HEAD as part
of the upcoming pg_constraint patch.

Fix contrib/xml2 makefile to not override CFLAGS.

Add more dependencies from libpgport required by
standalone msvc build of libpq.

Hiroshi Saito

The 8.2 patch that added support for an alias on the target table of
UPDATE/DELETE forgot to teach ruleutils.c to display the alias.
Per bug #4141 from Mathias Seiler.

Fix ALTER TABLE ADD COLUMN ... PRIMARY KEY so that the new column is correctly
checked to see if it's been initialized to all non-nulls.  The implicit NOT
NULL constraint was not being checked during the ALTER (in fact, not even if
there was an explicit NOT NULL too), because ATExecAddColumn neglected to
set the flag needed to make the test happen.  This has been broken since
the capability was first added, in 8.0.

Brendan Jurd, per a report from Kaloyan Iliev.

Fix using too many LWLocks bug, reported by Craig Ringer
<craig@postnewspapers.com.au>.
It was my mistake, I missed limitation of number of held locks, now GIN doesn't
use continiuous locks, but still hold buffers pinned to prevent interference
with vacuum's deletion algorithm.

Replace developer FAQ with a reference to the wiki, which is where
it now lives (per discussion). Leave the other FAQs alone for now.

Add link to major version release notes at the top of the minor
version ones, to make it clear to users just browsing the notes
that there are a lot more changes available from whatever version
they are at than what's in the minor version release notes.

Fix broken compare function for tsquery_ops. Per Tom's report.

I never understood why initial authors GiST in pgsql choose so
stgrange signature for 'same' method:
bool *sameFn(Datum a, Datum b, bool* result)
instead of simple, logical
bool sameFn(Datum a, Datum b)
This change will break any existing GiST extension, so we still live with
it and will live.

Repair two places where SIGTERM exit could leave shared memory state
corrupted.  (Neither is very important if SIGTERM is used to shut down the
whole database cluster together, but there's a problem if someone tries to
SIGTERM individual backends.)  To do this, introduce new infrastructure
macros PG_ENSURE_ERROR_CLEANUP/PG_END_ENSURE_ERROR_CLEANUP that take care
of transiently pushing an on_shmem_exit cleanup hook.  Also use this method
for createdb cleanup --- that wasn't a shared-memory-corruption problem,
but SIGTERM abort of createdb could leave orphaned files lying around.

Backpatch as far as 8.2.  The shmem corruption cases don't exist in 8.1,
and the createdb usage doesn't seem important enough to risk backpatching
further.

Fix LOAD_CRIT_INDEX() macro to take out AccessShareLock on the system index
it is trying to build a relcache entry for.  This is an oversight in my 8.2
patch that tried to ensure we always took a lock on a relation before trying
to build its relcache entry.  The implication is that if someone committed a
reindex of a critical system index at about the same time that some other
backend were starting up without a valid pg_internal.init file, the second one
might PANIC due to not seeing any valid version of the index's pg_class row.
Improbable case, but definitely not impossible.

Avoid using unnecessary pgwin32_safestat in libpq.

Add multi-line flag to regex that needs it. Backpatch to 8.2. Fix from Andreas Zeugswetter

A quick try at un-breaking the Cygwin build.  Whether it needs the
pgwin32_safestat remains to be determined, but in any case the current
code is not tolerable.

Fix several datatype input functions that were allowing unused bytes in their
results to contain uninitialized, unpredictable values.  While this was okay
as far as the datatypes themselves were concerned, it's a problem for the
parser because occurrences of the "same" literal might not be recognized as
equal by datumIsEqual (and hence not by equal()).  It seems sufficient to fix
this in the input functions since the only critical use of equal() is in the
parser's comparisons of ORDER BY and DISTINCT expressions.
Per a trouble report from Marc Cousin.

Patch all the way back.  Interestingly, array_in did not have the bug before
8.2, which may explain why the issue went unnoticed for so long.

Create wrapper pgwin32_safestat() and redefine stat() to it
on win32, because the stat() function in the runtime cannot
be trusted to always update the st_size field.

Per report and research by Sergey Zubkovsky.

Fixed bug in PGTYPEStimestamp_sub that used pointers instead of the values to substract.

Defend against JOINs having more than 32K columns altogether.  We cannot
currently support this because we must be able to build Vars referencing
join columns, and varattno is only 16 bits wide.  Perhaps this should be
improved in future, but considering that it never came up before, I'm not
sure the problem is worth much effort.  Per bug #4070 from Marcello
Ceschia.

The problem seems largely academic in 8.0 and 7.4, because they have
(different) O(N^2) performance issues with such wide joins, but
back-patch all the way anyway.

Fix a number of places that were making file-type tests infelicitously.
The places that did, eg,
(statbuf.st_mode & S_IFMT) == S_IFDIR
were correct, but there is no good reason not to use S_ISDIR() instead,
especially when that's what the other 90% of our code does.  The places
that did, eg,
(statbuf.st_mode & S_IFDIR)
were flat out *wrong* and would fail in various platform-specific ways,
eg a symlink could be mistaken for a regular file on most Unixen.

The actual impact of this is probably small, since the problem cases
seem to always involve symlinks or sockets, which are unlikely to be
found in the directories that PG code might be scanning.  But it's
clearly trouble waiting to happen, so patch all the way back anyway.
(There seem to be no occurrences of the mistake in 7.4.)

Fix core dump in contrib/xml2's xpath_table() when the input query returns
a NULL value.  Per bug #4058.

Adjust DatumGetBool macro so that it isn't fooled by garbage in the Datum
to the left of the actual bool value.  While in most cases there won't be
any, our support for old-style user-defined functions violates the C spec
to the extent of calling functions that might return char or short through
a function pointer declared to return "char *", which we then coerce to
Datum.  It is not surprising that the result might contain garbage
high-order bits ... what is surprising is that we didn't see such cases
long ago.  Per report from Magnus.

This is a back-patch of a change that was made in HEAD almost exactly
a year ago.  I had refrained from back-patching at the time, but now
we find that this is *necessary* for contrib to work with gcc 4.3.

Add the missing cyrillic "Yo" characters ('e' and 'E' with two dots) to the
ISO_8859-5 <-> MULE_INTERNAL conversion tables.

This was discovered when trying to convert a string containing those characters
from ISO_8859-5 to Windows-1251, because we use MULE_INTERNAL/KOI8R as an
intermediate encoding between those two.

While the missing "Yo" was just an omission in the conversion tables, there are
a few other characters like the "Numero" sign ("No" as a single character) that
exists in all the other cyrillic encodings (win1251, ISO_8859-5 and cp866), but
not in KOI8R. Added comments about that.

Patch by Sergey Burladyan. Back-patch to 7.4.

Fix regexp substring matching (substring(string from pattern)) for the corner
case where there is a match to the pattern overall but the user has specified
a parenthesized subexpression and that subexpression hasn't got a match.
An example is substring('foo' from 'foo(bar)?').  This should return NULL,
since (bar) isn't matched, but it was mistakenly returning the whole-pattern
match instead (ie, 'foo').  Per bug #4044 from Rui Martins.

This has been broken since the beginning; patch in all supported versions.
The old behavior was sufficiently inconsistent that it's impossible to believe
anyone is depending on it.

Translation updates

tag configure for 8.2.7 prior to tag

Stamp version 8.2.7, except for configure.in/configure.

Update release notes for 8.3.1 and 8.2.7 releases.

Update to tzdata 2008a distribution (Chilean DST law change).

Fix varstr_cmp's special case for UTF8 encoding on Windows so that strings
that are reported as "equal" by wcscoll() are checked to see if they really
are bitwise equal, and are sorted per strcmp() if not.  We made this happen
a couple of years ago in the regular code path, but it unaccountably got
left out of the Windows/UTF8 case (probably brain fade on my part at the
time).  As in the prior set of changes, affected users may need to reindex
indexes on textual columns.

Backpatch as far as 8.2, which is the oldest release we are still supporting
on Windows.

Fix LISTEN/NOTIFY race condition reported by Laurent Birtz, by postponing
pg_listener modifications commanded by LISTEN and UNLISTEN until the end
of the current transaction.  This allows us to hold the ExclusiveLock on
pg_listener until after commit, with no greater risk of deadlock than there
was before.  Aside from fixing the race condition, this gets rid of a
truly ugly kludge that was there before, namely having to ignore
HeapTupleBeingUpdated failures during NOTIFY.  There is a small potential
incompatibility, which is that if a transaction issues LISTEN or UNLISTEN
and then looks into pg_listener before committing, it won't see any resulting
row insertion or deletion, where before it would have.  It seems unlikely
that anyone would be depending on that, though.

This patch also disallows LISTEN and UNLISTEN inside a prepared transaction.
That case had some pretty undesirable properties already, such as possibly
allowing pg_listener entries to be made for PIDs no longer present, so
disallowing it seems like a better idea than trying to maintain the behavior.

Use -fwrapv in CFLAGS if we are using a version of gcc that accepts this flag.
This prevents compiler optimizations that assume overflow won't occur, which
breaks numerous overflow tests that we need to have working.  It is known
that gcc 4.3 causes problems and possible that 4.1 does.  Per my proposal
of some time ago and a recent report from Kris Jurka.

Backpatch as far as 8.0, which is as far as the patch conveniently goes.
7.x was pretty short of overflow tests anyway, so it may not matter there,
even assuming that anyone cares whether 7.x builds on recent gcc.

Change hashscan.c to keep its list of active hash index scans in
TopMemoryContext, rather than scattered through executor per-query contexts.
This poses no danger of memory leak since the ResourceOwner mechanism
guarantees release of no-longer-needed items.  It is needed because the
per-query context might already be released by the time we try to clean up
the hash scan list.  Report by ykhuang, diagnosis by Heikki.

Back-patch to 8.0, where the ResourceOwner-based cleanup was introduced.
The given test case does not fail before 8.2, probably because we rearranged
transaction abort processing somehow; but this coding is undoubtedly risky
so I'll patch 8.0 and 8.1 anyway.

Add support for dlopen on recent NetBSD/MIPS, per Rémi Zara.

In PrepareToInvalidateCacheTuple, don't force initialization of catalog
caches that we don't actually need to touch.  This saves some trivial
number of cycles and avoids certain cases of deadlock when doing concurrent
VACUUM FULL on system catalogs.  Per report from Gavin Roy.

Backpatch to 8.2.  In earlier versions, CatalogCacheInitializeCache didn't
lock the relation so there's no deadlock risk (though that certainly had
plenty of risks of its own).

Fix PREPARE TRANSACTION to reject the case where the transaction has dropped a
temporary table; we can't support that because there's no way to clean up the
source backend's internal state if the eventual COMMIT PREPARED is done by
another backend.  This was checked correctly in 8.1 but I broke it in 8.2 :-(.
Patch by Heikki Linnakangas, original trouble report by John Smith.

Venezuela Time now means UTC-4:30, not UTC-4:00.  Adjust our treatment
of "VET" accordingly.  Per bug #3997 from Aaron Mizrachi.

Don't call AddUserToDacl on Cygwin

Fix handling of restricted processes for Windows Vista (mainly),
by explicitly adding back the user to the DACL of the new process.
This fixes the failure case when executing as the Administrator
user, which had no permissions left at all after we dropped the
Administrators group.

Dave Page with some modifications from me

Fix several memory leaks when rescanning SRFs. Arrange for an SRF's
"multi_call_ctx" to be a distinct sub-context of the EState's per-query
context, and delete the multi_call_ctx as soon as the SRF finishes
execution. This avoids leaking SRF memory until the end of the current
query, which is particularly egregious when the SRF is scanned
multiple times. This change also fixes a leak of the fields of the
AttInMetadata struct in shutdown_MultiFuncCall().

Also fix a leak of the SRF result TupleDesc when rescanning a
FunctionScan node. The TupleDesc is allocated in the per-query context
for every call to ExecMakeTableFunctionResult(), so we should free it
after calling that function. Since the SRF might choose to return
a non-expendable TupleDesc, we only free the TupleDesc if it is
not being reference-counted.

Backpatch to 8.3 and 8.2 stable branches.

If RelationBuildDesc() fails to open a critical system index, PANIC with
a relevant error message instead of just dumping core.  Odd that nobody
reported this before Darren Reed.

Fix uninstall target.

Fix datetime input to behave correctly for Feb 29 in years BC.

Formerly, DecodeDate attempted to verify the day-of-the-month exactly, but
it was under the misapprehension that it would know whether we were looking
at a BC year or not.  In reality this check can't be made until the calling
function (eg DecodeDateTime) has processed all the fields.  So, split the
BC adjustment and validity checks out into a new function ValidateDate that
is called only after processing all the fields.  In passing, this patch
makes DecodeTimeOnly work for BC inputs, which it never did before.

(The historical veracity of all this is nonexistent, of course, but if
we're going to say we support proleptic Gregorian calendar then we should
do it correctly.  In any case the unpatched code is broken because it could
emit dates that it would then reject on re-inputting.)

Per report from Bernd Helmle.  Back-patch as far as 8.0; in 7.x we were
not using our own calendar support and so this seems a bit too risky
to put into 7.4.

Use our own getopt() and getopt_long() on Solaris, because that platform's
versions don't handle long options the way we want.  Per Zdenek Kotala.

Avoid trying to print a NULL char pointer in --describe-config.  On some
platforms this works, but on some it crashes.  Zdenek Kotala

Fix mistakes in pg_ctl's code for "start -w" that tries to cope with
non-default settings for the postmaster's port number.  The code to parse
command line options and postgresql.conf entries wasn't quite right about
whitespace or quotes, and it was coded in a not-very-readable way too.
Per bug #3969 from Itagaki Takahiro, though this is more extensive than his
proposed patch (which fixed only the whitespace problem).
This code has been broken since it was put in in 8.0, so patch all the way
back.

Put a CHECK_FOR_INTERRUPTS call into the loops that try to find a unique new
OID or new relfilenode.  If the existing OIDs are sufficiently densely
populated, this could take a long time (perhaps even be an infinite loop),
so it seems wise to allow the system to respond to a cancel interrupt here.
Per a gripe from Jacky Leng.

Backpatch as far as 8.1.  Older versions just fail on OID collision,
instead of looping.

EXECUTE can return NOT FOUND so it should be checked here too.

Added SQLSTATE macro closing bug #3961.

Update timezone mapping for Windows with new timezones added
in windows servicepacks.
Fix timezone mapping for "Mexico 2"

Repair VACUUM FULL bug introduced by HOT patch: the original way of
calculating a page's initial free space was fine, and should not have been
"improved" by letting PageGetHeapFreeSpace do it.  VACUUM FULL is going to
reclaim LP_DEAD line pointers later, so there is no need for a guard
against the page being too full of line pointers, and having one risks
rejecting pages that are perfectly good move destinations.

This also exposed a second bug, which is that the empty_end_pages logic
assumed that any page with no live tuples would get entered into the
fraged_pages list automatically (by virtue of having more free space than
the threshold in the do_frag calculation).  This assumption certainly
seems risky when a low fillfactor has been chosen, and even without
tunable fillfactor I think it could conceivably fail on a page with many
unused line pointers.  So fix the code to force do_frag true when notup
is true, and patch this part of the fix all the way back.

Per report from Tomas Szepe.

Some variants of ALTER OWNER tried to make the "object" field of the
statement be a list of bare C strings, rather than String nodes, which is
what they need to be for copyfuncs/equalfuncs to work.  Fortunately these
node types never go out to disk (if they did, we'd likely have noticed the
problem sooner), so we can just fix it without creating a need for initdb.
This bug has been there since 8.0, but 8.3 exposes it in a more common
code path (Parse messages) than prior releases did.  Per bug #3940 from
Vladimir Kokovic.

Fix WaitOnLock() to ensure that the process's "waiting" flag is reset after
erroring out of a wait.  We can use a PG_TRY block for this, but add a comment
explaining why it'd be a bad idea to use it for any other state cleanup.

Back-patch to 8.2.  Prior releases had the same issue, but only with respect
to the process title, which is likely to get reset almost immediately anyway
after the transaction aborts, so it seems not worth changing them.  In 8.2
and HEAD, the pg_stat_activity "waiting" flag could remain set incorrectly
for a long time.

Per report from Gurjeet Singh.

Improve pg_autovacuum documentation to clarify that the enabled field cannot
prevent anti-wraparound vacuuming, and to caution against setting unreasonably
small values of freeze_max_age.  Also put in a notice that this catalog is
likely to disappear entirely in some future release.  Per discussion of
bug #3898 from Steven Flatt.

Add pid to the pgident event name on win32.

Should fix a problem where two clusters are running under
two different service accounts and get colliding names,
causing only the first cluster to contain the pgident
event description.

Per report from Stephen Denne.

Prevent integer overflow within the integer-datetimes version of
TimestampTzPlusMilliseconds.  An integer argument of more than INT_MAX/1000
milliseconds (ie, about 35 minutes) would provoke a wrong result, resulting
in incorrect enforcement of statement_timestamp values larger than that.
Bug was introduced in my rewrite of 2006-06-20, which fixed some other
overflow risks, but missed this one :-(  Per report from Elein.

Work around for perl 5.10 bug - fix due to perl hacker Simon Cozens.

Backpatch my fix of rev 1.48 to avoid a division-by-zero error in the
cost-limit vacuum code.  Per trouble report from Joshua Drake.

Fix subselect.c to avoid assuming that a SubLink's testexpr references each
subquery output column exactly once left-to-right.  Although this is the case
in the original parser output, it might not be so after rewriting and
constant-folding, as illustrated by bug #3882 from Jan Mate.  Instead
scan the subquery's target list to obtain needed per-column information;
this is duplicative of what the parser did, but only a couple dozen lines
need be copied, and we can clean up a couple of notational uglinesses.
Bug was introduced in 8.2 as part of revision of SubLink representation.

Fix an ancient oversight in libpq's handling of V3-protocol COPY OUT mode:
we need to be able to swallow NOTICE messages, and potentially also
ParameterStatus messages (although the latter would be a bit weird),
without exiting COPY OUT state.  Fix it, and adjust the protocol documentation
to emphasize the need for this.  Per off-list report from Alexander Galler.

Fix logical errors in constraint exclusion: we cannot assume that a CHECK
constraint yields TRUE for every row of its table, only that it does not
yield FALSE (a NULL result isn't disallowed).  This breaks a couple of
implications that would be true in two-valued logic.  I had put in one such
mistake in an 8.2.5 patch: foo IS NULL doesn't refute a strict operator
on foo.  But there was another in the original 8.2 release: NOT foo doesn't
refute an expression whose truth would imply the truth of foo.
Per report from Rajesh Kumar Mallah.

To preserve the ability to do constraint exclusion with one partition
holding NULL values, extend relation_excluded_by_constraints() to check
for attnotnull flags, and add col IS NOT NULL expressions to the set of
constraints we hope to refute.

Fix a conceptual error in my patch of 2007-10-26 that avoided considering
clauseless joins of relations that have unexploited join clauses.  Rather
than looking at every other base relation in the query, the correct thing is
to examine the other relations in the "initial_rels" list of the current
make_rel_from_joinlist() invocation, because those are what we actually have
the ability to join against.  This might be a subset of the whole query in
cases where join_collapse_limit or from_collapse_limit or full joins have
prevented merging the whole query into a single join problem.  This is a bit
untidy because we have to pass those rels down through a new PlannerInfo
field, but it's necessary.  Per bug #3865 from Oleg Kharin.

Fix a bug in 8.2.x that was exposed while investigating Kevin Grittner's
report of poor planning in 8.3: it's unsafe to push a constant across an
outer join when the outer-join condition is delayed by lower outer joins,
unless we recheck the outer-join condition at the upper outer join.
8.2.x doesn't really have the ability to tell whether this is the case
or not, but fortunately it doesn't matter --- it seems most desirable to
keep the join condition whether it's entirely redundant or not.  However,
it's usually mostly redundant, so force its selectivity to 1.0.

It might be a good idea to back-patch this into 8.1 as well, but I'll
refrain until/unless there's evidence that 8.1 actually fails on any
cases that this would fix.