< * 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.

"make all", and then reference them there during the actual tests.  This
makes the handling of these files more parallel to that of regress.so,
and in particular simplifies use of the regression tests outside the
original build tree.  The PGDG and Red Hat RPMs have been doing this via
patches for a very long time.  Inclusion of the change in core was requested
by Jørgen Austvik of Sun, and I can't see any reason not to.

I attempted to fix the MSVC scripts for this too, but they may need
further tweaking ...

we are on a 64-bit machine (ie, size_t is wider than int) and someone passes
in a query string that approaches or exceeds INT_MAX bytes.  Also, just for
paranoia's sake, guard against similar overflows in sizing the input buffer.

The backend will not in the foreseeable future be prepared to send or receive
strings exceeding 1GB, so I didn't take the more invasive step of switching
all the buffer index variables from int to size_t; though someday we might
want to do that.

I have a suspicion that this is not the only such bug in libpq, but this
fix is enough to take care of the crash reported by Francisco Reyes.