visibilitymap.c by me.

types in CREATE TRIGGER.  While at it, clean up the amazingly tedious and
inextensible way that the trigger event type list was handled.  Per report
from Greg Sabino Mullane.

Most of those changes were good, but some not so good ...

aggregated tuple of a run.  Per report from Laurenz Albe.  This is a new
bug in 8.4, but only because prior versions rejected SRFs in an Agg plan
node altogether.

This prevents autovacuum from reclaiming free space in them and causing
the test's output row order to change, which is causing intermittent
bogus failure reports in the buildfarm.

Backpatch to 8.3.  The issue exists further back, but since autovacuum was
not on by default before 8.3, it's not a problem for buildfarm testing.

via hashing.  Eventually we ought to make that possible, but it won't happen
for 8.4.  Per yesterday's report from Robert Haas.

on hackers.  Also, take that string out of the translation roster, since
it's now entirely pseudo-SQL.

Dimitri Fontaine

without static.  Per testing with a compiler that complains about this.

time to tag rc1 ...

pg_migrator actually needs and not just a partial solution.  We have to be
able to specify the OID that the new toast table should be created with.

of getaddrinfo() to work.  Instead, recommend updating the OS to get a working
version of getaddrinfo.  Per recent discussions.

(Note: GiST penalty functions could possibly be non-strict, but none are at
present.)

Bangladesh, Egypt, Jordan, Pakistan.

function returning setof record.  This used to work, more or less
accidentally, but I had broken it while extending the code to allow
materialize-mode functions to be called in select lists.  Add a regression
test case so it doesn't get broken again.  Per gripe from Greg Davidson.

rsinfo->expectedDesc == NULL in deflist_to_tuplestore(), but that doesn't
look very safe to me.  Noted in passing while studying problem report
from Greg Davidson.

provided by Andrew.

of "syntax error", not the literal string.

This same change was made in the backend a while ago; but it applies to
plpgsql as well.

uninstall script to match reality.

reportedly is true on OpenBSD.  Also support OpenBSD's spelling of
-Wl,--as-needed.  Per Simon Bertrang.

in cursors.  This has always been the case, but given the lack of user
complaints about it, I'm not going to bother back-patching this.

node starts from the same place as the first scan did.  This avoids surprising
behavior of scrollable and WITH HOLD cursors, as seen in Mark Kirkwood's bug
report of yesterday.

It's not entirely clear whether a rescan should be forced to drop out of the
syncscan mode, but for the moment I left the code behaving the same on that
point.  Any change there would only be a performance and not a correctness
issue, anyway.

Back-patch to 8.3, since the unstable behavior was created by the syncscan
patch.

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.

In particular, always show 0 for the date type instead of null, and show
6 (the default) for time, timestamp, and interval without a declared
precision.  This is now in fuller conformance with the SQL standard.

Also clarify the documentation about this.

discovered and analyzed by Konstantin Izmailov and Tom Lane

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.