currently support this because we must be able to build Vars referencing
join columns, and varattno is only 16 bits wide.  Perhaps this should be
improved in future, but considering that it never came up before, I'm not
sure the problem is worth much effort.  Per bug #4070 from Marcello
Ceschia.

The problem seems largely academic in 8.0 and 7.4, because they have
(different) O(N^2) performance issues with such wide joins, but
back-patch all the way anyway.

returing right away.  This guarantees that when pg_stop_backup()
returns, you have a valid backup.

Simon Riggs

algorithm.  This is a good deal slower than our old roundoff-error-prone
code for long inputs, so we keep the old code for use in the transcendental
functions, where everything is approximate anyway.  Also create a
user-accessible function div(numeric, numeric) to provide access to the
exact result of trunc(x/y) --- since the regular numeric / operator will
round off its result, simply computing that expression in SQL doesn't
reliably give the desired answer.  This fixes bug #3387 and various related
corner cases, and improves the usefulness of PG for high-precision integer
arithmetic.

Greg Sabino Mullane

Greg Sabino Mullane

At the same time remove dblink/dblink_current_query() as it is no longer
necessary
*BACKWARD COMPATIBILITY ISSUE* for dblink

Tomas Doran

a make clean...

xmloption GUC variables into enums..

specify the cost values to use, instead of always using 1's.
Volkan Yazici

In passing, remove fuzzystrmatch.h, which contained a bunch of stuff that had
no business being in a .h file; fold it into its only user, fuzzystrmatch.c.

< * Allow encoding on a per-column basis optionally using the ICU library

>   http://wiki.postgresql.org/wiki/Todo:Collate
>   http://wiki.postgresql.org/wiki/Todo:ICU

heap_fetch a little.

> * Improve how ANALYZE computes in-doubt tuples
>
>   http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php
>

classed all as "dead"; also get it to count DEAD item pointers as dead rows,
instead of ignoring them as before.  Also improve matters so that tuples
previously inserted or deleted by our own transaction are handled nicely:
the stats collector's live-tuple and dead-tuple counts will end up correct
after our transaction ends, regardless of whether we end in commit or abort.

While there's more work that could be done to improve the counting of in-doubt
tuples in both VACUUM and ANALYZE, this commit is enough to alleviate some
known bad behaviors in 8.3; and the other stuff that's been discussed seems
like research projects anyway.

Pavan Deolasee and Tom Lane

Per buildfarm member mastodon.

* Add SQL:2003 WITH RECURSIVE (hierarchical) queries to SELECT

>   http://archives.postgresql.org/pgsql-patches/2008-01/msg00105.php
>   http://archives.postgresql.org/pgsql-patches/2008-03/msg00327.php

responsible for copying the query string into the new Portal.  Such copying
is unnecessary in the common code path through exec_simple_query, and in
this case it can be enormously expensive because the string might contain
a large number of individual commands; we were copying the entire, long
string for each command, resulting in O(N^2) behavior for N commands.
(This is the cause of bug #4079.)  A second problem with it is that
PortalDefineQuery really can't risk error, because if it elog's before
having set up the Portal, we will leak the plancache refcount that the
caller is trying to hand off to the portal.  So go back to the design in
which the caller is responsible for making sure everything is copied into
the portal if necessary.

default_transaction_isolation, session_replication_role and regex_flavor.

<
< * Prefix command-line utilities like createuser with 'pg_'
<
<   http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php
<

Pavel Stehule, with some improvements by myself.

that is commands that have out-of-line parameters but the plan is prepared
assuming that the parameter values are constants.  This is needed for the
plpgsql EXECUTE USING patch, but will probably have use elsewhere.

This commit includes the SPI functions and documentation, but no callers
nor regression tests.  The upcoming EXECUTE USING patch will provide
regression-test coverage.  I thought committing this separately made
sense since it's logically a distinct feature.

eval_const_expressions needs to be passed the PlannerInfo ("root") structure,
because in some cases we want it to substitute values for Param nodes.
(So "constant" is not so constant as all that ...)  This mistake partially
disabled optimization of unnamed extended-Query statements in 8.3: in
particular the LIKE-to-indexscan optimization would never be applied if the
LIKE pattern was passed as a parameter, and constraint exclusion depending
on a parameter value didn't work either.

Add some regression tests for plausible failures in this area.

while EState still contains pointers to those relations.  Exposed by the
CLOBBER_CACHE_ALWAYS tests that buildfarm member jaguar is running (I knew
those cycles would pay off...)

key files that are similar to the one for the postmaster's data directory
permissions check.  (I chose to standardize on that one since it's the most
heavily used and presumably best-wordsmithed by now.)  Also eliminate explicit
tests on file ownership in these places, since the ensuing read attempt must
fail anyway if it's wrong, and there seems no value in issuing the same error
message for distinct problems.  (But I left in the explicit ownership test in
postmaster.c, since it had its own error message anyway.)  Also be more
specific in the documentation's descriptions of these checks.  Per a gripe
from Kevin Hunter.

The places that did, eg,
	(statbuf.st_mode & S_IFMT) == S_IFDIR
were correct, but there is no good reason not to use S_ISDIR() instead,
especially when that's what the other 90% of our code does.  The places
that did, eg,
	(statbuf.st_mode & S_IFDIR)
were flat out *wrong* and would fail in various platform-specific ways,
eg a symlink could be mistaken for a regular file on most Unixen.

The actual impact of this is probably small, since the problem cases
seem to always involve symlinks or sockets, which are unlikely to be
found in the directories that PG code might be scanning.  But it's
clearly trouble waiting to happen, so patch all the way back anyway.
(There seem to be no occurrences of the mistake in 7.4.)

database size, when available to the current user.

Andrew Gilligan

\d output for a table.

Kenneth D'Souza, some changes by myself.

This requires a working 64-bit integer type. If such a type cannot
be found, "--disable-integer-datetimes" can be used to switch
back to the previous floating point-based datetime implementation.

Harald Armin Massa.

where the relation name was schema-qualified, for example
	UPDATE foo.bar SET <tab>
Also support cases where the relation name was quoted unnecessarily,
for example
	UPDATE "foo" SET <tab>

Greg Sabino Mullane, slightly simplified by myself.

Whatever we do about that, this isn't the path to the solution.

> * -Add ability to trigger on TRUNCATE

restore_command should report failure on non-existent .backup and .history
files. Tidy up some related text along the way.

Patch by Markus Bertheau, with some editing by Simon Riggs and myself.

>
> 	o Add CASE capability to language (already in SQL)
>
> 	  http://archives.postgresql.org/pgsql-hackers/2008-01/msg00696.php
>
>

> * Allow one transaction to see tuples using the snapshot of another
>   transaction
>
>   This would assist multiple backends in working together.
>   http://archives.postgresql.org/pgsql-hackers/2008-01/msg00400.php