One of these represents a nontrivial bug (a promptly-leaked palloc), so
backpatch.

Greg Stark

static checker.  Paul Matthews

and integer datetimes are in use.  Per bug report from Hubert Depesz
Lubaczewski.

Alex Hunsaker

The code in the new block was not reindented; it will be fixed by pgindent
eventually.

Pavel Stehule, Brendan Jurd

There are probably still some adjustments to be made in the details
of the output, but this gets the basic structure in place.

Robert Haas

Both hex format and the traditional "escape" format are automatically
handled on input.  The output format is selected by the new GUC variable
bytea_output.

As committed, bytea_output defaults to HEX, which is an *incompatible
change*.  We will keep it this way for awhile for testing purposes, but
should consider whether to switch to the more backwards-compatible
default of ESCAPE before 8.5 is released.

Peter Eisentraut

Add family of functions that did not exist earlier,
mainly due to historical omission. Original patch by
Abhijit Menon-Sen, with review and modifications by
Joe Conway. catversion.h bumped.

values being complained of.

In passing, also remove the arbitrary length limitation in the similar
error detail message for foreign key violations.

Itagaki Takahiro

include a fractional part in the output for MILLISECOND and SECOND cases,
rather than truncating the source value.  This is what the float-timestamp
code has always done, and it was clearly the code author's intent to do
the same for integer timestamps, but he forgot about integer division in C.
The other datatypes supported by EXTRACT() already do this correctly.

Backpatch to 8.4, so that the default (integer) behavior of that branch will
match the default (float) behavior of older branches.  Arguably we should
patch further back, but it's possible that applications are expecting the
broken behavior in older branches.  8.4 is new enough that expectations
shouldn't be too settled.

Per report from Greg Stark.

The current implementation fires an AFTER ROW trigger for each tuple that
looks like it might be non-unique according to the index contents at the
time of insertion.  This works well as long as there aren't many conflicts,
but won't scale to massive unique-key reassignments.  Improving that case
is a TODO item.

Dean Rasheed

 Aaron Marcuse-Kubitza <aaronmk@blackducksoftware.com>

This is believed to not change the output at all, with one known exception:
"Subquery Scan foo" becomes "Subquery Scan on foo".  (We can fix that if
anyone complains, but it would be a wart, because the old code was clearly
inconsistent.)  The main intention is to remove duplicate coding and
provide a cleaner base for subsequent EXPLAIN patching.

Robert Haas

of individually pfree'ing pass-by-reference transition values.  This should
be at least as fast as the prior coding, and it has the major advantage of
clearing out any working data an aggregate function may have stored in or
underneath the aggcontext.  This avoids memory leakage when an aggregate
such as array_agg() is used in GROUP BY mode.  Per report from Chris Spotts.

Back-patch to 8.4.  In principle the problem could arise in prior versions,
but since they didn't have array_agg the issue seems not critical.

This alters various incidental uses of C++ key words to use other similar
identifiers, so that a C++ compiler won't choke outright.  You still
(probably) need extern "C" { }; around the inclusion of backend headers.

based on a patch by Kurt Harriman <harriman@acm.org>

Also add a script cpluspluscheck to check for C++ compatibility in the
future.  As of right now, this passes without error for me.

Changes:

Pass in the keyword lookup array instead of having it be hardwired.
(This incidentally allows elimination of some duplicate coding in ecpg.)

Re-order the token declarations in gram.y so that non-keyword tokens have
numbers that won't change when keywords are added or removed.

Add ".." and ":=" to the set of tokens recognized by scan.l.  (Since these
combinations are nowhere legal in core SQL, this does not change anything
except the precise wording of the error you get when you write this.)

distinction between the external API (parser.h) and declarations that only
need to be visible within the raw parser code (gramparse.h, which now is only
included by parser.c, gram.y, scan.l, and keywords.c).  This is in preparation
for the upcoming change to a reentrant lexer, which will require referencing
YYSTYPE in the declarations of base_yylex and filtered_base_yylex, hence
gram.h will have to be included by gramparse.h.  We don't want any more files
than absolutely necessary to depend on gram.h, so some cleanup is called for.

meant or the reference to a standard was unnecessary.

timestamp_trunc, timestamptz_trunc, and interval_trunc().  This change
only affects the float-datetime case; the integer-datetime case already
behaved like truncation instead of rounding.  Per gripe from Mario Splivalo.

This is a pre-existing issue but I'm choosing not to backpatch, because
it's such a corner case and there have not been prior complaints.  The
issue is largely moot anyway given the trend towards integer datetimes.

In what seems like an oversight, we used to treat 'TH' the same as lowercase
'th', but only with HH/HH12.

a number of other geometric operators also depend on.  It miscalculated the
slope of the perpendicular to the given line segment anytime that slope was
other than 0, infinite, or +/-1.  In some cases the error would be masked
because the true closest point on the line segment was one of its endpoints
rather than the intersection point, but in other cases it could give an
arbitrarily bad answer.  Per bug #4872 from Nick Roosevelt.

Bug goes clear back to Berkeley days, so patch all supported branches.
Make a couple of cosmetic adjustments while at it.

even when not in FM mode.  This improves compatibility with Oracle and with
our pre-8.4 behavior, as per bug #4862.

Brendan Jurd

Add a couple of regression test cases for this.  In passing, get rid of the
labeling of the individual test cases; doesn't seem to be good for anything
except causing extra work when inserting a test...

Tom Lane

ArrayBuildState, per trouble report from Merlin Moncure.  By adopting
this fix, we are essentially deciding that aggregate final-functions
should not modify their inputs ever.  Adjust documentation and comments
to match that conclusion.

provided by Andrew.

eg Japan.  Report and fix by Itagaki Takahiro.  Also fix CASHDEBUG printout
format for branches with 64-bit money type, and some minor comment cleanup.

Back-patch to 7.4, because it's broken all the way back.

more consistent with other cases, by having an unlabeled integer field
be treated as a number of minutes or seconds respectively.  These cases
are outside the spec (which insists on full "dd hh:mm" or "dd hh:mm:ss"
input respectively), so it's not much help to us in deciding what to do.
But with this change, it's uniformly the case that an unlabeled integer
will be considered as being a number of the interval's rightmost field.
The change also takes us back to the 8.3 behavior of throwing error
for certain ambiguous inputs such as INTERVAL '1 2' DAY TO MINUTE.
Per recent discussion.

Sergey Burladyan, there are at least some dank corners of libxml2 that
assume this behavior, even though their published documentation suggests
they shouldn't.

This is only really a live problem in 8.3, but the code is still there
for possible debugging use in HEAD, so patch both branches.

Author: Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>

"array_agg_finalfn(null)".  We should modify pg_proc entries to prevent this
query from being accepted, but let's just make the function itself secure too.
Per my note of today.

pg_get_function_arguments() and related functions.  Per report from
Andreas Nolte.

also backpatched to 8.3

grounds that they don't fit into the specified interval qualifier (typmod).
This behavior, while of long standing, is clearly wrong per spec --- for
example the value INTERVAL '999' SECOND means 999 seconds and should not be
reduced to less than 60 seconds.

In some cases there could be grounds to raise an error if higher-order field
values are not given as zero; for example '1 year 1 month'::INTERVAL MONTH
should arguably be taken as an error rather than equivalent to 13 months.
However our internal representation doesn't allow us to do that in a fashion
that would consistently reject all and only the cases that a strict reading
of the spec would suggest.  Also, seeing that for example INTERVAL '13' MONTH
will print out as '1 year 1 mon', we have to be careful not to create a
situation where valid data will fail to dump and reload.  The present patch
therefore takes the attitude of not throwing an error in any such case.
We might want to revisit that in future but it would take more redesign
than seems prudent in late beta.

Per a complaint from Sebastien Flaesch and subsequent discussion.  While
at other times we might have just postponed such an issue to the next
development cycle, 8.4 already has changed the parsing of interval literals
quite a bit in an effort to accept all spec-compliant cases correctly.
This seems like a change that should be part of that rather than coming
along later.

YEAR, DECADE, CENTURY, or MILLENIUM fields, just as it always has done for
other types of fields.  The previous behavior seems to have been a hack to
avoid defining bit-positions for all these field types in DTK_M() masks,
rather than something that was really considered to be desired behavior.
But there is room in the masks for these, and we really need to tighten up
at least the behavior of DAY and YEAR fields to avoid unexpected behavior
associated with the 8.4 changes to interpret ambiguous fields based on the
interval qualifier (typmod) value.  Per my example and proposed patch.

"tsquery_op.c", line 193: warning: syntax error:  empty declaration

Zdenek Kotala

an expression that's not supposed to contain variables.  Per discussion
with Gevik Babakhani, this eliminates the need for an ugly kluge (namely,
specifying some unrelated relation name).  Remove one such kluge from
pg_dump.

EncodeTimeOnly, EncodeDateTime, EncodeInterval.  These don't have any good
reason to fail, and their callers were mostly not checking anyway.

of time values that would not be accepted via textual input.
Per gripe from Andrew McNamara.

This is potentially a back-patchable bug fix, but for the moment it doesn't
seem sufficiently high impact to justify doing that.