Base types are those, like int4, that
are implemented below the level of the SQL language (typically in a low-level
language such as C). They generally correspond to what are
often known as abstract data types. PostgreSQL can only operate on such types
through functions provided by the user and only understands the
behavior of such types to the extent that the user describes
them. Base types are further subdivided into scalar and array
types. For each scalar type, a corresponding array type is
automatically created that can hold variable-size arrays of
that scalar type.

Composite types, or row types, are created whenever the user
creates a table; it's also possible to define a "stand-alone" composite type with no associated
table. A composite type is simply a list of base types with
associated field names. A value of a composite type is a row or
record of field values. The user can access the component
fields from SQL queries.

A domain is based on a particular base type and for many
purposes is interchangeable with its base type. However, a
domain may have constraints that restrict its valid values to a
subset of what the underlying base type would allow.

Domains can be created using the SQL commands CREATE
DOMAIN. Their creation and use is not discussed in this
chapter.

There are a few "pseudo-types"
for special purposes. Pseudo-types cannot appear as columns of
tables or attributes of composite types, but they can be used
to declare the argument and result types of functions. This
provides a mechanism within the type system to identify special
classes of functions. Table
8-20 lists the existing pseudo-types.

Two pseudo-types of special interest are anyelement and anyarray,
which are collectively called polymorphic
types. Any function declared using these types is said to
be a polymorphic function. A
polymorphic function can operate on many different data types,
with the specific data type(s) being determined by the data
types actually passed to it in a particular call.

Polymorphic arguments and results are tied to each other and
are resolved to a specific data type when a query calling a
polymorphic function is parsed. Each position (either argument
or return value) declared as anyelement
is allowed to have any specific actual data type, but in any
given call they must all be the same actual type. Each position
declared as anyarray can have any array
data type, but similarly they must all be the same type. If
there are positions declared anyarray and
others declared anyelement, the actual
array type in the anyarray positions must
be an array whose elements are the same type appearing in the
anyelement positions.

Thus, when more than one argument position is declared with
a polymorphic type, the net effect is that only certain
combinations of actual argument types are allowed. For example,
a function declared as foo(anyelement,
anyelement) will take any two input values, so long as
they are of the same data type.

When the return value of a function is declared as a
polymorphic type, there must be at least one argument position
that is also polymorphic, and the actual data type supplied as
the argument determines the actual result type for that call.
For example, if there were not already an array subscripting
mechanism, one could define a function that implements
subscripting as subscript(anyarray,
integer) returns anyelement. This declaration constrains
the actual first argument to be an array type, and allows the
parser to infer the correct result type from the actual first
argument's type.