Represent type-specific length coercion functions as pg_cast entries,

eliminating the former hard-wired convention about their names.  Allow
pg_cast entries to represent both type coercion and length coercion in
a single step --- this is represented by a function that takes an
extra typmod argument, just like a length coercion function.  This
nicely merges the type and length coercion mechanisms into something
at least a little cleaner than we had before.  Make use of the single-
coercion-step behavior to fix integer-to-bit coercion so that coercing
to bit(n) yields the rightmost n bits of the integer instead of the
leftmost n bits.  This should fix recurrent complaints about the odd
behavior of this coercion.  Clean up the documentation of the bit string
functions, and try to put it where people might actually find it.
Also, get rid of the unreliable heuristics in ruleutils.c about whether
to display nested coercion steps; instead require parse_coerce.c to
label them properly in the first place.

doc/src/sgml/syntax.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.93 2004/06/07 04:04:47 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.94 2004/06/16 01:26:38 tgl Exp $
 -->
 
 <chapter id="sql-syntax">
@@ -1319,7 +1319,7 @@ CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable>
    <para>
     When a cast is applied to a value expression of a known type, it
     represents a run-time type conversion.  The cast will succeed only
-    if a suitable type conversion function is available.  Notice that this
+    if a suitable type conversion operation has been defined.  Notice that this
     is subtly different from the use of casts with constants, as shown in
     <xref linkend="sql-syntax-constants-generic">.  A cast applied to an
     unadorned string literal represents the initial assignment of a type