rows --- if the surrounding query queued any trigger events between the rows,
the events would be fired at the wrong time, leading to bizarre behavior.
Per report from Merlin Moncure.

This is a simple patch that should solve the problem fully in the back
branches, but in HEAD we also need to consider the possibility of queries
with RETURNING clauses.  Will look into a fix for that separately.

redefined-macro warnings on some platforms.  Per gripe from Hiroshi Saito.

No, I do not care whether Coverity considers this a memory leak.
It's entirely not worth the code space to do it correctly.

I introduced in 7.4.1 :-(.  It's correct to allow unknown to be coerced to
ANY or ANYELEMENT, since it's a real-enough data type, but it most certainly
isn't an array datatype.  This can cause a backend crash but AFAICT is not
exploitable as a security hole.  Per report from Michael Fuhr.

Note: as fixed in HEAD, this changes a constant in the pg_stats view,
resulting in a change in the expected regression outputs.  The back-branch
patches have been hacked to avoid that, so that pre-existing installations
won't start failing their regression tests.

don't cheat on the raw-vs-cooked status of a constraint.

'exist' and 'defined' accordingly. Old names
are saved not mentioned in docs - for compatibility
with old applications.
Per discussion
http://archives.postgresql.org/pgsql-hackers/2006-10/msg00571.php

Hiroshi Saito

        o copy FAQs from HEAD to top-most branches

to process all inclusion switches then all exclusion switches, so that the
behavior is independent of switch ordering.
Use of -T does not cause non-table objects to be suppressed.  And
the patterns are now interpreted the same way psql's \d commands do it,
rather than as pure regex commands; this allows for example -t schema.tab
to do what it should have been doing all along.  Re-enable the --blobs
switch to do something useful, ie, add back blobs into a dump they were
otherwise suppressed from.

commands (and soon by pg_dump).

pg_dump as well as psql.  Since psql already uses dumputils.c, while there's
not any code sharing in the other direction, this seems the easiest way.
Also, fix misinterpretation of patterns using regex | by adding parentheses
(same bug found previously in similar_escape()).  This should be backpatched.

Apple developer tools.  We now use dlopen directly if available, and fall
back to the older code if not.  Chris Campbell

on Win32.

specify it explicitly in backend/Makefile.  Arrange for this value to
be known by get_stack_depth_rlimit() too.  Per suggestion from Magnus.

per suggestion from Peter.  Without this, the main doc links prevent
those files from being built.

quote chars inside quote marks, should emit one quote *and stay in inquotes
mode*.  No doubt the lack of reports of this have something to do with the
poor documentation of the feature ...

portable long options.  But we have had portable long options for a long
time now, so this is obsolete.  Now people have added options which *only*
work with -X but not as regular long option, so I'm putting a stop to this:
-X is deprecated; it still works, but it has been removed from the
documentation, and please don't add more of them.

query_list into the Portal, ie, the one seen and possibly modified by
the planner.  My fault :-(  Per report from Sergey Koposov.

max_stack_depth is not set to an unsafe value.

This commit also provides configure-time checking for <sys/resource.h>,
and cleans up some perhaps-unportable code associated with use of that
include file and getrlimit().

platform limit, rather than just blindly raising max_stack_depth.
Also, tweak the code to work properly if someone sets max_stack_depth
to more than 2Gb, which guc.c will allow on a 64-bit machine.

overlapping possible matches for the separator string, such as
string_to_array('123xx456xxx789', 'xx').
Also, revise the logic of replace(), split_part(), and string_to_array()
to avoid O(N^2) work from redundant searches and conversions to pg_wchar
format when there are N matches to the separator string.
Backpatched the full patch as far as 8.0.  7.4 also has the bug, but the
code has diverged a lot, so I just went for a quick-and-dirty fix of the
bug itself in that branch.

win32.mak got patched for this, but not bcc32.mak.