← Back to branch summary

~ubuntu-branches/ubuntu/natty/postgresql-8.4/natty-security

« back to all changes in this revision

Viewing changes to doc/src/sgml/typeconv.sgml

  • Committer: Bazaar Package Importer
  • Author(s): Martin Pitt
  • Date: 2009-07-11 16:59:35 UTC
  • mfrom: (5.1.1 karmic)
  • Revision ID: james.westby@ubuntu.com-20090711165935-jfwin6gfrxf0gfsi
Tags: 8.4.0-2
http://bugs.debian.org/536139
* debian/libpq-dev.install: Ship catalog/genbki.h. (Closes: #536139)
* debian/rules: Drop --enable-cassert for final release.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/src/sgml/typeconv.sgml
1
 
<!-- $PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.59 2009/04/27 16:27:36 momjian Exp $ -->
 
1
<!-- $PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.60 2009/06/17 21:58:49 tgl Exp $ -->
2
2
 
3
3
<chapter Id="typeconv">
4
4
<title>Type Conversion</title>
161
161
user-defined.  (For a list see <xref linkend="catalog-typcategory-table">;
162
162
but note it is also possible to create custom type categories.)  Within each
163
163
category there can be one or more <firstterm>preferred types</firstterm>, which
164
 
are selected when there is ambiguity.  With careful selection
 
164
are preferred when there is a choice of possible types.  With careful selection
165
165
of preferred types and available implicit casts, it is possible to ensure that
166
166
ambiguous expressions (those with multiple candidate parsing solutions) can be
167
167
resolved in a useful way.
189
189
<para>
190
190
Additionally, if a query usually requires an implicit conversion for a function, and
191
191
if then the user defines a new function with the correct argument types, the parser
192
 
should use this new function and no longer do implicit conversion using the old function.
 
192
should use this new function and no longer do implicit conversion to use the old function.
193
193
</para>
194
194
</listitem>
195
195
</itemizedlist>
206
206
</indexterm>
207
207
 
208
208
  <para>
209
 
   The specific operator invoked is determined by the following
210
 
   steps. Note that this procedure is affected
211
 
   by the precedence of the involved operators.  See <xref
212
 
   linkend="sql-precedence"> for more information.
 
209
   The specific operator that is referenced by an operator expression
 
210
   is determined using the following procedure.
 
211
   Note that this procedure is indirectly affected
 
212
   by the precedence of the involved operators, since that will determine
 
213
   which sub-expressions are taken to be the inputs of which operators.
 
214
   See <xref linkend="sql-precedence"> for more information.
213
215
  </para>
214
216
 
215
217
<procedure>
220
222
Select the operators to be considered from the
221
223
<classname>pg_operator</classname> system catalog.  If a non-schema-qualified
222
224
operator name was used (the usual case), the operators
223
 
considered are those with a matching name and argument count that are
 
225
considered are those with the matching name and argument count that are
224
226
visible in the current search path (see <xref linkend="ddl-schemas-path">).
225
227
If a qualified operator name was given, only operators in the specified
226
228
schema are considered.
250
252
<para>
251
253
If one argument of a binary operator invocation is of the <type>unknown</type> type,
252
254
then assume it is the same type as the other argument for this check.
253
 
Cases involving two <type>unknown</type> types will never find a match at
254
 
this step.
 
255
Invocations involving two <type>unknown</type> inputs, or a unary operator
 
256
with an <type>unknown</type> input, will never find a match at this step.
255
257
</para>
256
258
</step>
257
259
</substeps>
390
392
are specified in the query. So, the parser looks for all candidate operators
391
393
and finds that there are candidates accepting both string-category and
392
394
bit-string-category inputs.  Since string category is preferred when available,
393
 
that category is selected, and the
 
395
that category is selected, and then the
394
396
preferred type for strings, <type>text</type>, is used as the specific
395
 
type to resolve the unknown literals.
 
397
type to resolve the unknown literals as.
396
398
</para>
397
399
</example>
398
400
 
459
461
</indexterm>
460
462
 
461
463
  <para>
462
 
   The specific function to be invoked is determined
463
 
   according to the following steps.
 
464
   The specific function that is referenced by a function call
 
465
   is determined using the following procedure.
464
466
  </para>
465
467
 
466
468
<procedure>
471
473
Select the functions to be considered from the
472
474
<classname>pg_proc</classname> system catalog.  If a non-schema-qualified
473
475
function name was used, the functions
474
 
considered are those with a matching name and argument count that are
 
476
considered are those with the matching name and argument count that are
475
477
visible in the current search path (see <xref linkend="ddl-schemas-path">).
476
478
If a qualified function name was given, only functions in the specified
477
479
schema are considered.
554
556
<substeps>
555
557
<step performance="required">
556
558
<para>
557
 
Discard candidate functions in which the input types do not match
 
559
Discard candidate functions for which the input types do not match
558
560
and cannot be converted (using an implicit conversion) to match.
559
561
<type>unknown</type> literals are
560
562
assumed to be convertible to anything for this purpose.  If only one
615
617
<title>Rounding Function Argument Type Resolution</title>
616
618
 
617
619
<para>
618
 
There is only one <function>round</function> function which takes two
619
 
arguments;  it takes a first argument of <type>numeric</type> and 
620
 
a second argument of <type>integer</type>.  So the following query automatically converts
 
620
There is only one <function>round</function> function that takes two
 
621
arguments; it takes a first argument of type <type>numeric</type> and
 
622
a second argument of type <type>integer</type>.
 
623
So the following query automatically converts
621
624
the first argument of type <type>integer</type> to
622
625
<type>numeric</type>:
623
626