1
0
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:
Tom Lane
2008-07-30 19:35:13 +00:00
parent 42be2c790f
commit 7df49cef72
9 changed files with 116 additions and 128 deletions

View File

@ -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>

View File

@ -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: