avoid a later needless VACUUM for Xid-wraparound purposes.  We can do this
since the table is known to be left empty, so no Xid remains on it.

Per discussion.

applied to live tuples older than a recent Xmin, not to tuples that may be part
of an update chain.  Those still keep their original markings.

This patch makes it possible for CLUSTER to advance relfrozenxid, thus avoiding
the need of vacuuming the table for Xid wraparound purposes.  That will be
patched separately.

Patch from Heikki Linnakangas.

when the grantor has been dropped.  This is a workaround for the fact
that we don't track the grantor as a shared dependency.

Workaround for when it is: include the ossp directory using --with-includes.

information" is un-good English.

parentheses in syntax descriptions. Consistently use the present tense
when describing the basic purpose of each "DROP" command. Add a few
more hyperlinks.

that require alignment.

Add a paragraph to the "User-Defined Types" chapter on using these
macros since it seems like they're a hit.

Gregory Stark

launcher daemon.

"autovacuum = off", the system may still periodically start autovacuum
processes to prevent XID wraparound. Patch from David Fetter, with
editorializing.

* Add support for SQL-standard GENERATED/IDENTITY columns

>   http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php
>   http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php

there's an indirect dependency on the owner via the parent table.  We were
already handling indexes that way, but not toast tables for some reason.
Saves a little catalog space and cuts down the verbosity of checkSharedDependencies
reports.

patch; also make the code logic a bit more self-consistent.

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