As previously mentioned, there are two kinds of types in
Postgres: base types (defined in a
programming language) and composite types (instances). Examples in
this section up to interfacing indices can be found in complex.sql and complex.c. Composite examples are in funcs.sql.

A user-defined type must always have input and output functions.
These functions determine how the type appears in strings (for
input by the user and output to the user) and how the type is
organized in memory. The input function takes a null-delimited
character string as its input and returns the internal (in memory)
representation of the type. The output function takes the internal
representation of the type and returns a null delimited character
string. Suppose we want to define a complex type which represents
complex numbers. Naturally, we choose to represent a complex in
memory as the following C
structure:

typedef struct Complex {
double x;
double y;
} Complex;

and a string of the form (x,y) as the external string
representation. These functions are usually not hard to write,
especially the output function. However, there are a number of
points to remember:

When defining your external (string) representation,
remember that you must eventually write a complete and robust
parser for that representation as your input function!

You should try to make the input and output functions
inverses of each other. If you do not, you will have severe
problems when you need to dump your data into a file and then
read it back in (say, into someone else's database on another
computer). This is a particularly common problem when
floating-point numbers are involved.

To define the complex type, we need
to create the two user-defined functions complex_in and complex_out
before creating the type:

As discussed earlier, Postgres
fully supports arrays of base types. Additionally, Postgres supports arrays of user-defined types
as well. When you define a type, Postgres automatically provides support for
arrays of that type. For historical reasons, the array type has the
same name as the user-defined type with the underscore character _
prepended. Composite types do not need any function defined on
them, since the system already understands what they look like
inside.

The types discussed to this point are all "small" objects --
that is, they are smaller than 8KB in size.

Note: 1024 longwords == 8192 bytes. In fact, the type
must be considerably smaller than 8192 bytes, since the
Postgres tuple and page overhead
must also fit into this 8KB limitation. The actual value that
fits depends on the machine architecture.

If you require a larger type for something like a
document retrieval system or for storing bitmaps, you will need to
use the Postgres large object
interface, or will need to recompile the Postgres backend to use internal storage
blocks greater than 8kbytes..