Flip the default typispreferred setting from true to false. This affects

only type categories in which the previous coding made *every* type
preferred; so there is no change in effective behavior, because the function
resolution rules only do something different when faced with a choice
between preferred and non-preferred types in the same category.  It just
seems safer and less surprising to have CREATE TYPE default to non-preferred
status ...

2 files changed, 6 insertions, 18 deletions

diff --git a/doc/src/sgml/ref/create_type.sgml b/doc/src/sgml/ref/create_type.sgml
index 8002e2c4b9c..665bc805af8 100644
--- a/doc/src/sgml/ref/create_type.sgml
+++ b/doc/src/sgml/ref/create_type.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/create_type.sgml,v 1.75 2008/07/30 17:05:04 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/create_type.sgml,v 1.76 2008/07/30 19:35:12 tgl Exp $
 PostgreSQL documentation
 -->
 
@@ -535,9 +535,9 @@ CREATE TYPE <replaceable class="parameter">name</replaceable>
     <listitem>
      <para>
       True if this type is a preferred type within its type category,
-      else false.  The default is true (which is appropriate for
-      all entries in category <literal>U</>, but is usually not
-      appropriate for new types in other categories &mdash; beware!).
+      else false.  The default is false.  Be very careful about creating
+      a new preferred type within an existing type category, as this
+      could cause surprising changes in behavior.
      </para>
     </listitem>
    </varlistentry>
diff --git a/doc/src/sgml/typeconv.sgml b/doc/src/sgml/typeconv.sgml
index c9f96323f30..08b62c4e61a 100644
--- a/doc/src/sgml/typeconv.sgml
+++ b/doc/src/sgml/typeconv.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.56 2008/07/30 17:05:04 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.57 2008/07/30 19:35:12 tgl Exp $ -->
 
 <chapter Id="typeconv">
 <title>Type Conversion</title>
@@ -160,25 +160,13 @@ categories</firstterm>, including <type>boolean</type>, <type>numeric</type>,
 <type>timespan</type>, <type>geometric</type>, <type>network</type>, and
 user-defined.  (For a list see <xref linkend="catalog-typcategory-table">;
 but note it is also possible to create custom type categories.)  Within each
-category there are one or more <firstterm>preferred types</firstterm>, which
+category there can be one or more <firstterm>preferred types</firstterm>, which
 are preferentially selected when there is ambiguity.  With careful selection
 of preferred types and available implicit casts, it is possible to ensure that
 ambiguous expressions (those with multiple candidate parsing solutions) can be
 resolved in a useful way.
 </para>
 
-<note>
- <para>
-  For what are now historical reasons, types in the <quote>user-defined</>
-  category are normally always marked as <quote>preferred</>.  Since all types
-  in this category are preferred, the heuristic that favors preferred types
-  accomplishes nothing, and thus this situation is equivalent to treating them
-  all as non-preferred.  The <quote>preferred</> marking is useful within the
-  system-defined type categories, and can be useful within custom type
-  categories.
- </para>
-</note>
-
 <para>
 All type conversion rules are designed with several principles in mind: