Como se describe en la sección Section 36.2, PostgreSQL puede extenderse para admitir nuevos data types. Esta sección describe cómo definir nuevos tipos base, que son tipos de datos definidos por debajo del nivel del lenguaje SQL. La creación de un nuevo tipo base requiere la implementación de funciones para operar sobre el tipo en un lenguaje de bajo nivel, generalmente C.

Los ejemplos de esta sección se pueden encontrar en complex.sql y complex.c en el directorio src/tutorial de la distribución de las fuentes. Consulta el archivo README en ese directorio para obtener instrucciones sobre cómo ejecutar los ejemplos.

Un tipo definido por el usuario siempre debe tener funciones de entrada y salida. Estas funciones determinan cómo aparece el tipo en las cadenas de texto (para la entrada por parte del usuario y la salida hacia el usuario) y cómo se organiza el tipo en la memoria. La función de entrada toma una cadena de caracteres terminada en cero como argumento y devuelve la representación interna (en memoria) del tipo. La función de salida toma la representación interna del tipo como argumento y devuelve una cadena de caracteres terminada en cero. Si queremos hacer algo más con el tipo además de simplemente almacenarlo, debemos proporcionar funciones adicionales para implementar cualquier operación que queramos que tenga el tipo.

Supongamos que queremos definir un tipo complex que represente números complejos. Una forma natural de representar un número complejo en memoria sería la siguiente estructura en C:

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

Tendremos que hacer que este sea un tipo por referencia (pass-by-reference), ya que es demasiado grande para caber en un solo valor Datum.

Como representación de cadena externa del tipo, elegimos una cadena con el formato (x,y).

Las funciones de entrada y salida no suelen ser difíciles de escribir, especialmente la función de salida. Sin embargo, al definir la representación de cadena externa del tipo, recuerda que eventualmente tendrás que escribir un analizador (parser) completo y robusto para esa representación como tu función de entrada. Por ejemplo:

PG_FUNCTION_INFO_V1(complex_in);

Datum
complex_in(PG_FUNCTION_ARGS)
{
    char       *str = PG_GETARG_CSTRING(0);
    double      x,
                y;
    Complex    *result;

    if (sscanf(str, " ( %lf , %lf )", &x, &y) != 2)
        ereport(ERROR,
                (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
                 errmsg("invalid input syntax for type %s: \"%s\"",
                        "complex", str)));

    result = (Complex *) palloc(sizeof(Complex));
    result->x = x;
    result->y = y;
    PG_RETURN_POINTER(result);
}

La función de salida puede ser simplemente:

PG_FUNCTION_INFO_V1(complex_out);

Datum
complex_out(PG_FUNCTION_ARGS)
{
    Complex    *complex = (Complex *) PG_GETARG_POINTER(0);
    char       *result;

    result = psprintf("(%g,%g)", complex->x, complex->y);
    PG_RETURN_CSTRING(result);
}

Debes tener cuidado de hacer que las funciones de entrada y salida sean inversas entre sí. Si no lo haces, tendrás graves problemas cuando necesites volcar tus datos en un archivo y luego volver a leerlos. Este es un problema particularmente común cuando se trata de números de coma flotante.

Opcionalmente, un tipo definido por el usuario puede proporcionar rutinas de entrada y salida binarias. La E/S binaria normalmente es más rápida pero menos portable que la E/S de texto. Al igual que con la E/S de texto, depende de ti definir exactamente cuál es la representación binaria externa. La mayoría de los tipos de datos integrados intentan proporcionar una representación binaria independiente de la máquina. Para complex, nos apoyaremos en los convertidores de E/S binaria para el tipo float8:

PG_FUNCTION_INFO_V1(complex_recv);

Datum
complex_recv(PG_FUNCTION_ARGS)
{
    StringInfo  buf = (StringInfo) PG_GETARG_POINTER(0);
    Complex    *result;

    result = (Complex *) palloc(sizeof(Complex));
    result->x = pq_getmsgfloat8(buf);
    result->y = pq_getmsgfloat8(buf);
    PG_RETURN_POINTER(result);
}

PG_FUNCTION_INFO_V1(complex_send);

Datum
complex_send(PG_FUNCTION_ARGS)
{
    Complex    *complex = (Complex *) PG_GETARG_POINTER(0);
    StringInfoData buf;

    pq_begintypsend(&buf);
    pq_sendfloat8(&buf, complex->x);
    pq_sendfloat8(&buf, complex->y);
    PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
}

Una vez que hayamos escrito las funciones de E/S y las hayamos compilado en una biblioteca compartida, podemos definir el tipo complex en SQL. Primero lo declaramos como un tipo shell (shell type):

CREATE TYPE complex;

Esto sirve como un marcador de posición que nos permite hacer referencia al tipo mientras definimos sus funciones de E/S. Ahora podemos definir las funciones de E/S:

CREATE FUNCTION complex_in(cstring)
    RETURNS complex
    AS 'filename'
    LANGUAGE C IMMUTABLE STRICT;

CREATE FUNCTION complex_out(complex)
    RETURNS cstring
    AS 'filename'
    LANGUAGE C IMMUTABLE STRICT;

CREATE FUNCTION complex_recv(internal)
   RETURNS complex
   AS 'filename'
   LANGUAGE C IMMUTABLE STRICT;

CREATE FUNCTION complex_send(complex)
   RETURNS bytea
   AS 'filename'
   LANGUAGE C IMMUTABLE STRICT;

Finalmente, podemos proporcionar la definición completa del tipo de datos:

CREATE TYPE complex (
   internallength = 16,
   input = complex_in,
   output = complex_out,
   receive = complex_recv,
   send = complex_send,
   alignment = double
 );

Cuando defines un nuevo tipo base, PostgreSQL proporciona automáticamente soporte para arrays de ese tipo. El tipo de array normalmente tiene el mismo nombre que el tipo base precedido por el carácter de subrayado (_).

Una vez que el tipo de datos existe, podemos declarar funciones adicionales para proporcionar operaciones útiles sobre el tipo de datos. Luego se pueden definir operadores sobre las funciones y, si es necesario, se pueden crear clases de operadores para admitir la indexación del tipo de datos. Estas capas adicionales se analizan en las siguientes secciones.

Si la representación interna del tipo de datos es de longitud variable, la representación interna debe seguir el diseño estándar para datos de longitud variable: los primeros cuatro bytes deben ser un campo char[4] al que nunca se accede directamente (habitualmente denominado vl_len_). Debes utilizar la macro SET_VARSIZE() para almacenar el tamaño total del dato (incluyendo el propio campo de longitud) en este campo y VARSIZE() para recuperarlo. (Estas macros existen porque el campo de longitud puede codificarse según la plataforma).

Para más detalles, consulta la descripción del comando CREATE TYPE.