This adds support for the more or less SQL-conforming USAGE privilege
on types and domains.  The intent is to be able restrict which users
can create dependencies on types, which restricts the way in which
owners can alter types.

reviewed by Yeb Havinga

There is what may actually be a mistake in our markup.  The problem is
in a situation like

<para>
 <command>FOO</command> is ...

there is strictly speaking a line break before "FOO".  In the HTML
output, this does not appear to be a problem, but in the man page
output, this shows up, so you get double blank lines at odd places.

So far, we have attempted to work around this with an XSL hack, but
that causes other problems, such as creating run-ins in places like

<acronym>SQL</acronym> <command>COPY</command>

So fix the problem properly by removing the extra whitespace.  I only
fixed the problems that affect the man page output, not all the
places.

documentation.  Per suggestion from Marc Cousin.

In HEAD, emit a warning when an operator named => is defined.
In both HEAD and the backbranches (except in 8.2, where contrib
modules do not have documentation), document that hstore's text =>
text operator may be removed in a future release, and encourage the
use of the hstore(text, text) function instead.  This function only
exists in HEAD (previously, it was called tconvert), so backpatch
it back to 8.2, when hstore was added.  Per discussion.

The endterm attribute is mainly useful when the toolchain does not support
automatic link target text generation for a particular situation.  In  the
past, this was required by the man page tools for all reference page links,
but that is no longer the case, and it now actually gets in the way of
proper automatic link text generation.  The only remaining use cases are
currently xrefs to refsects.

another section if required by the platform (instead of the old way of
building them in section "l" and always transforming them to the
platform-specific section).

This speeds up the installation on common platforms, and it avoids some
funny business with the man page tools and build process.

appropriate.

Standard English uses "may", "can", and "might" in different ways:

        may - permission, "You may borrow my rake."

        can - ability, "I can lift that log."

        might - possibility, "It might rain today."

Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice.  Similarly, "It may crash" is better stated, "It might crash".

cases.  Operator classes now exist within "operator families".  While most
families are equivalent to a single class, related classes can be grouped
into one family to represent the fact that they are semantically compatible.
Cross-type operators are now naturally adjunct parts of a family, without
having to wedge them into a particular opclass as we had done originally.

This commit restructures the catalogs and cleans up enough of the fallout so
that everything still works at least as well as before, but most of the work
needed to actually improve the planner's behavior will come later.  Also,
there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way
to create a new family right now is to allow CREATE OPERATOR CLASS to make
one by default.  I owe some more documentation work, too.  But that can all
be done in smaller pieces once this infrastructure is in place.

aggregates, conversions, functions, operators, operator classes,
schemas, types, and tablespaces.  Fold the existing implementations
of alter domain owner and alter database owner in with these.

Christopher Kings-Lynne

$Header: -> $PostgreSQL Changes ...

discussion.  (Still have some work to do editing the remainder.)

are now driven by the default btree opclass, rather than assuming that
particular operator names have the needed semantics.

vague cross-references with real links.

including:

- replacing all the appropriate usages of <citetitle>PostgreSQL
...</citetitle> with &cite-user;, &cite-admin;, and so on

- fix an omission in the EXECUTE documentation

- add some more text to the EXPLAIN documentation

- improve the PL/PgSQL RETURN NEXT documentation (more work to do here)

- minor markup fixes


Neil Conway

settings of NAMEDATALEN. I looked through the docs for other
references to NAMEDATALEN, but this is the only one I could find.

Neil Conway

arguments of CREATE OPERATOR.

 capabilities of specifying time zones as intervals per SQL9x.
Put refentrytitle contents on the same line as the tag.
 Otherwise, leading whitespace is propagated into the product, which
 (at least) messes up the ToC layout.
Remove (some) docinfo tags containing dates. Best to omit if the dates
 are not accurate; maybe use CVS dates instead or leave them out.

qualified operator names directly, for example CREATE OPERATOR myschema.+
( ... ).  To qualify an operator name in an expression you need to write
OPERATOR(myschema.+) (thanks to Peter for suggesting an escape hatch).
I also took advantage of having to reformat pg_operator to fix something
that'd been bugging me for a while: mergejoinable operators should have
explicit links to the associated cross-data-type comparison operators,
rather than hardwiring an assumption that they are named < and >.

 between Postgres and PostgreSQL.

===================
In Notes:
 Refer to CREATE FUNCTION for information on creating aggregate functions.
                                                      ^^^^^^^^^^^^^^^^^^^
I assume it must read C function instead.

In Compatibility SQL/PSM:
 SQL/PSM is a proposed standard.

 We had that before: remove proposed.


drop_index.sgml:
================
<REFNAME>: Removes existing indexes from a database

as far as I can see index should be singular. The command description is
written as if only one index can be removed at a time. Interestingly
enough, in v7.0.2 it was in fact singular. Am I mistaken here?

drop_operator.sgml:
===================
In Outputs the arguments are referred to as type and type2, but the synopsis
and Inputs section these are left_type and right_type, respectively. Also,
oper is used in Outputs versus id in Inputs/Synopsis. In the translation I
follow the replaceables used in the Inputs/Synopsis part.

Frank Wegmann