array, (Datum)value);

}

array_varchareq(ArrayType*array,void*value)

{

returnarray_iterator(F_VARCHAREQ,

0,/* logical or */

array, (Datum)value);

}

array_all_varchareq(ArrayType*array,void*value)

{

returnarray_iterator(F_VARCHAREQ,

1,/* logical and */

array, (Datum)value);

}

array_varcharregexeq(ArrayType*array,void*value)

{

returnarray_iterator(F_TEXTREGEXEQ,

0,/* logical or */

array, (Datum)value);

}

array_all_varcharregexeq(ArrayType*array,void*value)

{

returnarray_iterator(F_TEXTREGEXEQ,

1,/* logical and */

array, (Datum)value);

}

int32array_textregexeq(ArrayType*array,void*value);

int32array_all_textregexeq(ArrayType*array,void*value);

int32array_varchareq(ArrayType*array,void*value);

int32array_all_varchareq(ArrayType*array,void*value);

int32array_varcharregexeq(ArrayType*array,void*value);

int32array_all_varcharregexeq(ArrayType*array,void*value);

int32array_bpchareq(ArrayType*array,void*value);

int32array_all_bpchareq(ArrayType*array,void*value);

int32array_bpcharregexeq(ArrayType*array,void*value);

);

-- define the array operators *=, **=, *~ and **~ for type _varchar

--

-- NOTE: "varchar" is also a reserved word and must be quoted.

--

CREATE OR REPLACE FUNCTION array_varchareq(_varchar, varchar)

RETURNS bool

AS 'MODULE_PATHNAME'

LANGUAGE 'C' IMMUTABLE STRICT;

CREATE OR REPLACE FUNCTION array_all_varchareq(_varchar, varchar)

RETURNS bool

AS 'MODULE_PATHNAME'

LANGUAGE 'C' IMMUTABLE STRICT;

CREATE OR REPLACE FUNCTION array_varcharregexeq(_varchar, varchar)

RETURNS bool

AS 'MODULE_PATHNAME'

LANGUAGE 'C' IMMUTABLE STRICT;

CREATE OR REPLACE FUNCTION array_all_varcharregexeq(_varchar, varchar)

RETURNS bool

AS 'MODULE_PATHNAME'

LANGUAGE 'C' IMMUTABLE STRICT;

DROP OPERATOR *=(_varchar,"varchar");

CREATE OPERATOR *= (

LEFTARG=_varchar,

RIGHTARG="varchar",

PROCEDURE=array_varchareq

);

DROP OPERATOR **=(_varchar,"varchar");

CREATE OPERATOR **= (

LEFTARG=_varchar,

RIGHTARG="varchar",

PROCEDURE=array_all_varchareq

);

DROP OPERATOR *~(_varchar,"varchar");

CREATE OPERATOR *~ (

LEFTARG=_varchar,

RIGHTARG="varchar",

PROCEDURE=array_varcharregexeq

);

DROP OPERATOR **~(_varchar,"varchar");

CREATE OPERATOR **~ (

LEFTARG=_varchar,

RIGHTARG="varchar",

PROCEDURE=array_all_varcharregexeq

);

-- define the array operators *=, **=, *~ and **~ for type _bpchar

--

CREATE OR REPLACE FUNCTION array_bpchareq(_bpchar, bpchar)

<!--

$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.189 2003/05/22 18:31:45 tgl Exp $

$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.190 2003/05/26 00:11:27 tgl Exp $

-->

<appendix id="release">

worries about funny characters.

-->

<literallayout><![CDATA[

CHAR(n) to TEXT conversion automatically strips trailing blanks

Pattern matching operations can use indexes regardless of locale

New frontend/backend protocol supports many long-requested features

SET AUTOCOMMIT TO OFF is no longer supported

<!--

$Header: /cvsroot/pgsql/doc/src/sgml/typeconv.sgml,v 1.30 2003/03/25 16:15:38 petere Exp $

$Header: /cvsroot/pgsql/doc/src/sgml/typeconv.sgml,v 1.31 2003/05/26 00:11:27 tgl Exp $

-->

<chapter Id="typeconv">

<para>

The <productname>PostgreSQL</productname> scanner/parser decodes lexical

elements into only five fundamental categories: integers, floating-point numbers, strings,

names, and key words.Most extended types are first classified as

names, and key words.Constants of most non-numeric types are first classified as

strings. The <acronym>SQL</acronym> language definition allows specifying type

names with strings, and this mechanism can be used in

<productname>PostgreSQL</productname> to start the parser down the correct

perform those conversions. Additional casts can be added by the user

with the <command>CREATE CAST</command> command. (This is usually

done in conjunction with defining new data types. The set of casts

between the built-in types has been carefully crafted andshould not

bealtered.)

between the built-in types has been carefully crafted andis best not

altered.)

</para>

<para>

several basic <firstterm>type categories</firstterm> defined: <type>boolean</type>,

<type>numeric</type>, <type>string</type>, <type>bitstring</type>, <type>datetime</type>, <type>timespan</type>, <type>geometric</type>, <type>network</type>,

and user-defined. Each category, with the exception of user-defined, has

a<firstterm>preferredtype</firstterm> whichis preferentially selected

when there is ambiguity.

one or more<firstterm>preferredtypes</firstterm> whichare preferentially

selectedwhen there is ambiguity.

In the user-defined category, each type is its own preferred type.

Ambiguous expressions (those with multiple candidate parsing solutions)

can therefore often be resolved when there are multiple possible built-in types, but

<para>

User-defined types are not related. Currently, <productname>PostgreSQL</productname>

does not have information available to it on relationships between types, other than

hardcoded heuristics for built-in types and implicit relationships based on available functions.

hardcoded heuristics for built-in types and implicit relationships based on

available functions and casts.

</para>

</listitem>

<title>Operators</title>

<para>

The operand types of an operator invocation are resolved following

The specific operator to be used in an operator invocation is determined

by following

the procedure below. Note that this procedure is indirectly affected

by the precedence of the involved operators. See <xref

linkend="sql-precedence"> for more information.

</para>

<procedure>

<title>Operand Type Resolution</title>

<title>Operator Type Resolution</title>

<step performance="required">

<para>

<step performance="required">

<para>

Run through all candidates and keep those with the most exact matches

on input types. Keep all candidates if none have any exact matches.

on input types. (Domain types are considered the same as their base type

for this purpose.) Keep all candidates if none have any exact matches.

If only one candidate remains, use it; else continue to the next step.

</para>

</step>

<step performance="required">

<para>

Run through all candidates and keep those with the most exact or

binary-compatible matches on input types. Keep all candidates if none have

any exact or binary-compatible matches.

If only one candidate remains, use it; else continue to the next step.

</para>

</step>

<step performance="required">

<para>

Run through all candidates and keep those that accept preferred types at

the most positions where type conversion will be required.

Run through all candidates and keep those that accept preferred types (of the

input datatype's type category) at the most positions where type conversion

will be required.

Keep all candidates if none accept preferred types.

If only one candidate remains, use it; else continue to the next step.

</para>

<para>

If any input arguments are <type>unknown</type>, check the type

categories accepted at those argument positions by the remaining

candidates. At each position, select the <literal>string</literal> category if any

candidates. At each position, select the <type>string</type> category

if any

candidate accepts that category. (This bias towards string is appropriate

since an unknown-type literal does look like a string.) Otherwise, if

all the remaining candidates accept the same type category, select that

category; otherwise fail because the correct choice cannot be deduced

without more clues. Now discard operator

without more clues. Now discard

candidates that do not accept the selected type category. Furthermore,

if any candidate accepts a preferred type at a given argument position,

discard candidates that accept non-preferred types for that argument.

<title>Functions</title>

<para>

Theargument types of function calls are resolved according to the

following steps.

Thespecific function to be used in a function invocation is determined

according to thefollowing steps.

</para>

<procedure>

<title>FunctionArgumentType Resolution</title>

<title>Function Type Resolution</title>

<step performance="required">

<para>

<step performance="required">

<para>

Run through all candidates and keep those with the most exact matches

on input types. Keep all candidates if none have any exact matches.

If only one candidate remains, use it; else continue to the next step.

</para>

</step>

<step performance="required">

<para>

Run through all candidates and keep those with the most exact or

binary-compatible matches on input types. Keep all candidates if none have

any exact or binary-compatible matches.

on input types. (Domain types are considered the same as their base type

for this purpose.) Keep all candidates if none have any exact matches.

If only one candidate remains, use it; else continue to the next step.

</para>

</step>

<step performance="required">

<para>

Run through all candidates and keep those that accept preferred types at

the most positions where type conversion will be required.

Run through all candidates and keep those that accept preferred types (of the

input datatype's type category) at the most positions where type conversion

will be required.

Keep all candidates if none accept preferred types.

If only one candidate remains, use it; else continue to the next step.

</para>

</step>

<step performance="required">

<para>

If any input arguments are <type>unknown</type>, check the type categories accepted

If any input arguments are <type>unknown</type>, check the type categories

accepted

at those argument positions by the remaining candidates. At each position,

select the <type>string</type> category if any candidate accepts that category.

(This bias towards string

is appropriate since an unknown-type literal does look like a string.)

Otherwise, if all the remaining candidates accept the same type category,

select that category; otherwise fail because

the correct choice cannot be deduced without more clues.

Now discard candidates that do not accept the selected type category;

furthermore, if any candidate accepts a preferred type at a given argument

Now discard candidates that do not accept the selected type category.

Furthermore, if any candidate accepts a preferred type at a given argument

position, discard candidates that accept non-preferred types for that

argument.

</para>

</procedure>

<para>

Note that the <quote>best match</> rules are identical for operator and

function type resolution.

Some examples follow.

</para>

<para>

<note>

<para>

The parser is aware that <type>text</type> and <type>varchar</type>

The parser learns from the <structname>pg_cast</> catalog that

<type>text</type> and <type>varchar</type>

are binary-compatible, meaning that one can be passed to a function that

accepts the other without doing any physical conversion. Therefore, no

explicit type conversion call is really inserted in this case.