objects are specified, we drop them all in a single performMultipleDeletions
call.  This makes the RESTRICT/CASCADE checks more relaxed: it's not counted
as a cascade if one of the later objects has a dependency on an earlier one.
NOTICE messages about such cases go away, too.

In passing, fix the permissions check for DROP CONVERSION, which for some
reason was never made role-aware, and omitted the namespace-owner exemption
too.

Alex Hunsaker, with further fiddling by me.

> 	o Add functions to syntax check configuration files
>
< * Add pg_ctl option to do a syntax check of postgresql.conf

the problem happened in.  These are all supposedly can't-happen cases, but
when they do happen it's useful to know where.

Back-patch to 8.3, but not further because the patch doesn't apply cleanly
further back.  Given the lack of response to my proposal of this, there
doesn't seem to be enough interest to justify much back-porting effort.

< * Allow INSERT/UPDATE ... RETURNING inside a SELECT 'FROM' clause
> * Allow INSERT/UPDATE ... RETURNING inside a SELECT 'FROM' clause or
>   target list
>   http://archives.postgresql.org/pgsql-hackers/2008-06/msg00124.php

forks. XLogOpenRelation() and the associated light-weight relation cache in
xlogutils.c is gone, and XLogReadBuffer() now takes a RelFileNode as argument,
instead of Relation.

For functions that still need a Relation struct during WAL replay, there's a
new function called CreateFakeRelcacheEntry() that returns a fake entry like
XLogOpenRelation() used to.

devised for pg_shdepend, namely the individual dependencies are reported as
DETAIL lines rather than coming out as separate NOTICEs.  The client-side
report is capped at 100 lines, but the server log always gets a full report.

> * Add pg_ctl option to do a syntax check of postgresql.conf

Greg Sabino Mullane

argument.

David Fetter.

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.

Basically just reuse the same text that psql emitted as part of
its startup banner in prior versions, and make some whitespace
more consistent with the conventions in other psql command output.

replacing the tedious and error-prone manual process we've been using.

Per Jan Urbanski.

recently snuck into cash.c.  Per report from Edmundo Robles Lopez.

Jun Kuwamura

running on a 64-bit platform ... strtol() will happily return 64-bit
output in that case.  Per bug #4231 from Geoff Tolley.

is testing.  Ah, the perils of making keywords optional ...

algorithm, replacing the original intention of a one-pass search, which
had been hacked up over time to be partially two-pass in hopes of handling
various corner cases better.  It still wasn't quite there, especially as
regards emitting unwanted NOTICE messages.  More importantly, this approach
lets us fix a number of open bugs concerning concurrent DROP scenarios,
because we can take locks during the first pass and avoid traversing to
dependent objects that were just deleted by someone else.

There is more that can be done here, but I'll go ahead and commit the
base patch before working on the options.

more logical that way, and also it reduces the amount of unnecessary includes
in bufpage.h, which is widely used.

Zdenek Kotala.

My previous patch to bufpage.h should also have credited him as author, but I
forgot (sorry about that).

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.

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.

always pass as a single element anyway.)  In passing, fix an outdated comment.

doesn't work, and the real reason why not is it's unclear where the path
is relative to (initdb's CWD, or the data directory?).  We could make an
arbitrary decision, but it seems best to make the user be unambiguous.
Per gripe from Devrim.

Morocco, Iraq, Choibalsan, Pakistan, Syria, Cuba, Argentina/San_Luis).

the PARAM_FLAG_CONST flag on the parameters that are passed into the portal,
while the former's behavior is unchanged.  This should only affect the case
where the portal is executing an EXPLAIN; it will cause the generated plan to
look more like what would be generated if the portal were actually executing
the command being explained.  Per gripe from Pavel.