mirror of
https://github.com/postgres/postgres.git
synced 2025-07-28 23:42:10 +03:00
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 ...
This commit is contained in:
@ -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 — 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>
|
||||
|
@ -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:
|
||||
|
||||
|
Reference in New Issue
Block a user