ActiveSnapshot.  Having it affect ActiveSnapshot only in the unusual
case of needing to replan seems a bad idea, and there's also the problem
that the created snap might be in a relatively short-lived context, as
noted by Jan Wieck.  Also, there's no need to force a new snap at all
unless we are called with no snap currently set, which is an unusual
case in itself.

and only a truncated log of the objects in the current database to the client.
Also, instead of reporting object counts for all databases on which the user
might own objects, report only as many as fit in the predefined line count.

This is to avoid flooding the client when the user owns too many objects,
which could cause problems.

Per report from Ed L. on April 4th and subsequent discussion.

Per request from Andrew Dunstan.

< 	o Add support for arrays of complex types
>
> 	  http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php
>
> 	o -Add support for arrays of complex types

> * Have configure choose integer datetimes by default
>
>   http://archives.postgresql.org/pgsql-patches/2007-05/msg00046.php

> 		o Allow data to be passed in native language formats, rather
> 		  than only text
> 		  http://archives.postgresql.org/pgsql-hackers/2007-05/msg00289.php

more completely.  The motivation for having it understand IS NULL at all was
to allow use of "foo IS NULL" as one of the subsets of a partitioning on
"foo", but as reported by Aleksander Kmetec, it wasn't really getting the job
done.  Backpatch to 8.2 since this is arguably a performance bug.

named foo, would work but the other ordering would not.  If a user-specified
type or table name collides with an existing auto-generated array name, just
rename the array type out of the way by prepending more underscores.  This
should not create any backward-compatibility issues, since the cases in which
this will happen would have failed outright in prior releases.

Also fix an oversight in the arrays-of-composites patch: ALTER TABLE RENAME
renamed the table's rowtype but not its array type.

needs to check the new constraint against columns of derived domains too.

Also, make it error out if the domain to be modified is used within any
composite-type columns.  Eventually we should support that case, but it seems
a bit painful, and not suitable for a back-patch.  For the moment just let the
user know we can't do it.

Backpatch to 8.2, which is the only released version that allows nested
domains.  Possibly the other part should be back-patched further.

and views (but not system catalogs, nor sequences or toast tables).  Get rid
of the hardwired convention that a type's array type is named exactly "_type",
instead using a new column pg_type.typarray to provide the linkage.  (It still
will be named "_type", though, except in odd corner cases such as
maximum-length type names.)

Along the way, make tracking of owner and schema dependencies for types more
uniform: a type directly created by the user has these dependencies, while a
table rowtype or auto-generated array type does not have them, but depends on
its parent object instead.

David Fetter, Andrew Dunstan, Tom Lane

- Renamed update test so it hopefully runs on Vista

datatype project.  Per request from Ale Raza (araza at esri.com).

numerics as "oprcanhash", and make the corresponding system catalog
updates. As a result, hash indexes, hashed aggregation, and hash
joins can now be used with the numeric type. Bump the catversion.

The only tricky aspect to doing this is writing a correct hash
function: it's possible for two Numerics to be equal according to
their equality operator, but have different in-memory bit patterns.
To cope with this, the hash function doesn't consider the Numeric's
"scale" or "sign", and explictly skips any leading or trailing
zeros in the Numeric's digit buffer (the current implementation
should suppress any such zeros, but it seems unwise to rely upon
this). See discussion on pgsql-patches for more details.

sign convention from everyplace else in Postgres.  I don't suppose that
this will stop people from being confused, but at least we can say that
it's documented.

It makes PGCLIENTENCODING work again and uses bsearch() instead of
iterating over the array of guc variables in guc_get_index().

Joachim Wieland

now".  This can happen if the time granularity is not very high.

Per ITAGAKI Takahiro.

non-standard way of indicating errors, so we don't try to
allocate INT_MAX bytes to store a result in.

< Last updated:		Sat May  5 10:47:39 EDT 2007
> Last updated:		Sat May  5 11:39:57 EDT 2007
< * Flush cached query plans when the dependent objects change,
<   when the cardinality of parameters changes dramatically, or
> * -Flush cached query plans when the dependent objects change or
<
<   A more complex solution would be to save multiple plans for different
<   cardinality and use the appropriate plan based on the EXECUTE values.
<
< * Track dependencies in function bodies and recompile/invalidate
<
<   This is particularly important for references to temporary tables
<   in PL/PgSQL because PL/PgSQL caches query plans.  The only workaround
<   in PL/PgSQL is to use EXECUTE.  One complexity is that a function
<   might itself drop and recreate dependent tables, causing it to
<   invalidate its own query plan.
<
< * Invalidate prepared queries, like INSERT, when the table definition
> * -Track dependencies in function bodies and recompile/invalidate
> * -Invalidate prepared queries, like INSERT, when the table definition

< * Invalidate prepared queries, like INSERT, when the table definition
<   is altered
>
> * Invalidate prepared queries, like INSERT, when the table definition
>   is altered

> 	o -Allow multiple vacuums so large tables do not starve small

> * -Allow ORDER BY ... LIMIT # to select high/low value without sort or
<
<   Right now, if no index exists, ORDER BY ... LIMIT # requires we sort
<   all values to return the high/low value.  Instead The idea is to do a
<   sequential scan to find the high/low value, thus avoiding the sort.
<   MIN/MAX already does this, but not for LIMIT > 1.
<

actual sort strategy and amount of space used.  By popular demand.

Make clearer how arguments and return values in pl/perl are escaped. This is to clarify the situation that Theo Schlossnagle recently reported on -bugs.

and for other compilers, insert a dummy exit() call so that they understand
PG_RE_THROW() doesn't return.  Insert fflush(stderr) in ExceptionalCondition,
per recent buildfarm evidence that that might not happen automatically on some
platforms.  And const-ify ExceptionalCondition's declaration while at it.

need be returned.  We keep a heap of the current best N tuples and sift-up
new tuples into it as we scan the input.  For M input tuples this means
only about M*log(N) comparisons instead of M*log(M), not to mention a lot
less workspace when N is small --- avoiding spill-to-disk for large M
is actually the most attractive thing about it.  Patch includes planner
and executor support for invoking this facility in ORDER BY ... LIMIT
queries.  Greg Stark, with some editorialization by moi.

pages it intends to zero immediately.  Just to show there is some use for that
function besides WAL recovery :-).
Along the way, fold _hash_checkpage and _hash_pageinit calls into _hash_getbuf
and friends, instead of expecting callers to do that separately.

the relevant fixes to 8.2 as well.

for local symbols, that shouldn't be exported. This patch excludes them,
cutting down about 10,000 exported symbols and decreasing the binary size
by 20%.