seems unnecessary to mention in the FAQ, per discussion on IRC.

the columns it works with to be domains over the expected type, not just
exactly the expected type.  In passing, fix ts_stat() the same way.
Per report from Markus Wollny.

Should fix regression test failures on those platforms.

default as other platforms.

Should fix build failures on AIX.

modules are built.  Foremost, it creates a solid distinction between these two
types of targets based on what had already been implemented and duplicated in
ad hoc ways before.  Specifically,

- Dynamically loadable modules no longer get a soname.  The numbers previously
set in the makefiles were dummy numbers anyway, and the presence of a soname
upset a few packaging tools, so it is nicer not to have one.

- The cumbersome detour taken on installation (build a libfoo.so.0.0.0 and
then override the rule to install foo.so instead) is removed.

- Lots of duplicated code simplified.

>
> 	o Add ability to obfuscate function bodies
>
> 	  http://archives.postgresql.org/pgsql-patches/2008-01/msg00125.php

expressions.

for improved compatibility with Oracle.

Pavel Stehule, with some fixes by me.

data.  This makes for a significant speedup at the cost that the results
now vary between little-endian and big-endian machines; which forces us
to add explicit ORDER BYs in a couple of regression tests to preserve
machine-independent comparison results.  Also, force initdb by bumping
catversion, since the contents of hash indexes will change (at least on
big-endian machines).

Kenneth Marshall and Tom Lane, based on work from Bob Jenkins.  This commit
does not adopt Bob's new faster mix() algorithm, however, since we still need
to convince ourselves that that doesn't degrade the quality of the hashing.

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.