results to contain uninitialized, unpredictable values.  While this was okay
as far as the datatypes themselves were concerned, it's a problem for the
parser because occurrences of the "same" literal might not be recognized as
equal by datumIsEqual (and hence not by equal()).  It seems sufficient to fix
this in the input functions since the only critical use of equal() is in the
parser's comparisons of ORDER BY and DISTINCT expressions.
Per a trouble report from Marc Cousin.

Patch all the way back.  Interestingly, array_in did not have the bug before
8.2, which may explain why the issue went unnoticed for so long.

< * Allow functions to control the transaction state
> * Allow calling of a procedure outside a SELECT that can control the
>   transaction state

< * Support procedures, which return no value
> * Allow functions to control the transaction state

> * Support procedures, which return no value
>
>   http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php

Brendan Jurd

indexscan always occurs in one call, and the results are returned in a
TIDBitmap instead of a limited-size array of TIDs.  This should improve
speed a little by reducing AM entry/exit overhead, and it is necessary
infrastructure if we are ever to support bitmap indexes.

In an only slightly related change, add support for TIDBitmaps to preserve
(somewhat lossily) the knowledge that particular TIDs reported by an index
need to have their quals rechecked when the heap is visited.  This facility
is not really used yet; we'll need to extend the forced-recheck feature to
plain indexscans before it's useful, and that hasn't been coded yet.
The intent is to use it to clean up 8.3's horrid @@@ kluge for text search
with weighted queries.  There might be other uses in future, but that one
alone is sufficient reason.

Heikki Linnakangas, with some adjustments by me.

>   http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php
>   http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php
>   http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php
>   http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php
>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00014.php
>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00487.php
> * Allow index scans to return matching index keys
>
>   http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php
>
>   http://archives.postgresql.org/pgsql-patches/2007-10/msg00166.php
>   http://archives.postgresql.org/pgsql-patches/2008-01/msg00049.php

on win32, because the stat() function in the runtime cannot
be trusted to always update the st_size field.

Per report and research by Sergey Zubkovsky.

the prototype. Silences msvc build warning.

to the monitoring section.

Jim Nasby

you can't get a simultaneous snapshot.

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