Si se especifica, la tabla se crea como una tabla temporal. Las tablas temporales se eliminan automáticamente al final de una sesión, o opcionalmente al final de la transacción actual (consulta ON COMMIT más abajo). El search_path por defecto incluye primero el esquema temporal, por lo que las tablas permanentes existentes con el mismo nombre no se eligen para nuevos planes mientras exista la tabla temporal, a menos que se haga referencia a ellas con nombres calificados por esquema. Cualquier índice creado en una tabla temporal también es automáticamente temporal.

El demonio de autovacuum no puede acceder y, por lo tanto, no puede realizar vacuum o analyze en tablas temporales. Por esta razón, se deben realizar las operaciones de vacuum y analyze apropiadas mediante comandos SQL de sesión. Por ejemplo, si se va a utilizar una tabla temporal en consultas complejas, es aconsejable ejecutar ANALYZE en la tabla temporal después de que se haya llenado de datos.

Opcionalmente, se puede escribir GLOBAL o LOCAL antes de TEMPORARY o TEMP. Actualmente esto no hace ninguna diferencia en PostgreSQL y está obsoleto; consulta Compatibilidad más abajo.

Si se especifica, la tabla se crea como una tabla no registrada (unlogged). Los datos escritos en tablas no registradas no se escriben en el registro de escritura anticipada (WAL, consulta Chapter 28), lo que las hace considerablemente más rápidas que las tablas ordinarias. Sin embargo, no son seguras ante caídas: una tabla no registrada se trunca automáticamente después de una caída o un apagado no limpio. El contenido de una tabla no registrada tampoco se replica a los servidores en espera (standbys). Cualquier índice creado en una tabla no registrada también es automáticamente no registrado.

Si se especifica esto, cualquier secuencia creada junto con la tabla no registrada (para columnas identity o serial) también se crea como no registrada.

Esta forma no es compatible con tablas particionadas.

No arroja un error si ya existe una relación con el mismo nombre. En este caso se emite una advertencia. Ten en cuenta que no hay garantía de que la relación existente sea similar a la que se habría creado.

El nombre (opcionalmente calificado por esquema) de la tabla a crear.

Crea una tabla tipada, que toma su estructura del tipo compuesto independiente especificado (es decir, uno creado usando CREATE TYPE) aunque también produce un nuevo tipo compuesto. La tabla tendrá una dependencia del tipo referenciado, lo que significa que las acciones alter y drop en cascada en ese tipo se propagarán a la tabla.

Una tabla tipada siempre tiene los mismos nombres de columna y tipos de datos que el tipo del que se deriva, por lo que no puedes especificar columnas adicionales. Pero el comando CREATE TABLE puede añadir valores por defecto y restricciones a la tabla, así como especificar parámetros de almacenamiento.

El nombre de una columna que se va a crear en la nueva tabla.

El tipo de datos de la columna. Esto puede incluir especificadores de array. Para obtener más información sobre los tipos de datos compatibles con PostgreSQL, consulta Chapter 8.

La cláusula COLLATE asigna una ordenación a la columna (que debe ser de un tipo de datos ordenable). Si no se especifica, se utiliza la ordenación por defecto del tipo de datos de la columna.

Esta forma establece el modo de almacenamiento para la columna. Esto controla si esta columna se mantiene en línea (inline) o en una tabla secundaria TOAST, y si los datos deben comprimirse o no. PLAIN debe usarse para valores de longitud fija como integer y es en línea, sin comprimir. MAIN es para datos en línea y comprimibles. EXTERNAL es para datos externos y sin comprimir, y EXTENDED es para datos externos y comprimidos. Escribir DEFAULT establece el modo de almacenamiento al modo por defecto para el tipo de datos de la columna. EXTENDED es el valor por defecto para la mayoría de los tipos de datos que admiten almacenamiento que no sea PLAIN. El uso de EXTERNAL hará que las operaciones de subcadena en valores text y bytea muy grandes se ejecuten más rápido, a costa de un mayor espacio de almacenamiento. Consulta Section 66.2 para obtener más información.

La cláusula COMPRESSION establece el método de compresión para la columna. La compresión es compatible solo para tipos de datos de ancho variable, y se usa solo cuando el modo de almacenamiento de la columna es main o extended. (Consulta ALTER TABLE para obtener información sobre los modos de almacenamiento de columnas.) Establecer esta propiedad para una tabla particionada no tiene un efecto directo, porque tales tablas no tienen almacenamiento propio, pero el valor configurado será heredado por las particiones recién creadas. Los métodos de compresión admitidos son pglz y lz4. (lz4 está disponible solo si se usó la opción --with-lz4 al construir PostgreSQL.) Además, método_compresión puede ser default para especificar explícitamente el comportamiento por defecto, que consiste en consultar el parámetro de configuración default_toast_compression en el momento de la inserción de datos para determinar el método a utilizar.

La cláusula opcional INHERITS especifica una lista de tablas de las cuales la nueva tabla hereda automáticamente todas las columnas. Las tablas padre pueden ser tablas ordinarias o tablas foráneas.

El uso de INHERITS crea una relación persistente entre la nueva tabla hija y su(s) tabla(s) padre. Las modificaciones de esquema en las tablas padre normalmente también se propagan a las hijas, y por defecto los datos de la tabla hija se incluyen en los escaneos de las tablas padre.

Si existe el mismo nombre de columna en más de una tabla padre, se reporta un error a menos que los tipos de datos de las columnas coincidan en cada una de las tablas padre. Si no hay conflicto, las columnas duplicadas se fusionan para formar una sola columna en la nueva tabla. Si la lista de nombres de columna de la nueva tabla contiene un nombre de columna que también es heredado, el tipo de datos también debe coincidir con la(s) columna(s) heredada(s), y las definiciones de las columnas se fusionan en una sola. Si la nueva tabla especifica explícitamente un valor por defecto para la columna, este valor por defecto anula cualquier valor por defecto de las declaraciones heredadas de la columna. De lo contrario, cualquier padre que especifique valores por defecto para la columna debe especificar el mismo valor por defecto, o de lo contrario se reportará un error.

Las restricciones CHECK se fusionan esencialmente de la misma manera que las columnas: si varias tablas padre y/o la definición de la nueva tabla contienen restricciones CHECK con el mismo nombre, estas restricciones deben tener todas la misma expresión de comprobación, o de lo contrario se reportará un error. Las restricciones que tengan el mismo nombre y expresión se fusionarán en una sola copia. No se considerará una restricción marcada como NO INHERIT en un padre. Ten en cuenta que una restricción CHECK sin nombre en la nueva tabla nunca se fusionará, ya que siempre se elegirá un nombre único para ella.

La configuración de STORAGE de las columnas también se copia de las tablas padre.

Si una columna en la tabla padre es una columna de identidad, esa propiedad no se hereda. Una columna en la tabla hija puede declararse como columna de identidad si se desea.

La cláusula opcional PARTITION BY especifica una estrategia de particionamiento para la tabla. La tabla así creada se denomina tabla particionada. La lista entre paréntesis de columnas o expresiones forma la clave de partición de la tabla. Al utilizar particionamiento por rango o hash, la clave de partición puede incluir varias columnas o expresiones (hasta 32, pero este límite se puede modificar al construir PostgreSQL), pero para el particionamiento por lista, la clave de partición debe consistir en una sola columna o expresión.

El particionamiento por rango y lista requiere una clase de operador btree, mientras que el particionamiento hash requiere una clase de operador hash. Si no se especifica explícitamente una clase de operador, se utilizará la clase de operador por defecto del tipo apropiado; si no existe una clase de operador por defecto, se producirá un error. Cuando se utiliza particionamiento hash, la clase de operador utilizada debe implementar la función de soporte 2 (consulta Section 36.16.3 para obtener detalles).

Una tabla particionada se divide en subtablas (llamadas particiones), que se crean mediante comandos CREATE TABLE independientes. La tabla particionada en sí está vacía. Una fila de datos insertada en la tabla se enruta a una partición en función del valor de las columnas o expresiones en la clave de partición. Si ninguna partición existente coincide con los valores de la nueva fila, se reportará un error.

Consulta Section 5.12 para obtener más información sobre el particionamiento de tablas.

Crea la tabla como una partición de la tabla padre especificada. La tabla se puede crear como una partición para valores específicos usando FOR VALUES o como una partición por defecto usando DEFAULT. Cualquier índice, restricción y disparador (trigger) a nivel de fila definido por el usuario que exista en la tabla padre se clonará en la nueva partición.

La especificación_límite_partición debe corresponder al método de particionamiento y a la clave de partición de la tabla padre, y no debe superponerse con ninguna partición existente de ese padre. La forma con IN se utiliza para el particionamiento por lista, la forma con FROM y TO se utiliza para el particionamiento por rango, y la forma con WITH se utiliza para el particionamiento hash.

expr_límite_partición es cualquier expresión libre de variables (no se permiten subconsultas, funciones de ventana, funciones agregadas ni funciones que devuelven conjuntos). Su tipo de datos debe coincidir con el tipo de datos de la columna de la clave de partición correspondiente. La expresión se evalúa una vez en el momento de la creación de la tabla, por lo que incluso puede contener expresiones volátiles como CURRENT_TIMESTAMP.

Al crear una partición por lista, se puede especificar NULL para indicar que la partición permite que la columna de la clave de partición sea nula. Sin embargo, no puede haber más de una partición por lista de este tipo para una tabla padre determinada. No se puede especificar NULL para particiones por rango.

Al crear una partición por rango, el límite inferior especificado con FROM es un límite inclusivo, mientras que el límite superior especificado con TO es un límite exclusivo. Es decir, los valores especificados en la lista FROM son valores válidos de las columnas de la clave de partición correspondiente para esta partición, mientras que los de la lista TO no lo son. Ten en cuenta que esta afirmación debe entenderse de acuerdo con las reglas de comparación por filas (Section 9.25.5). Por ejemplo, dado PARTITION BY RANGE (x,y), un límite de partición FROM (1, 2) TO (3, 4) permite x=1 con cualquier y>=2, x=2 con cualquier y que no sea nulo, y x=3 con cualquier y<4.

Los valores especiales MINVALUE y MAXVALUE se pueden utilizar al crear una partición por rango para indicar que no hay un límite inferior o superior en el valor de la columna. Por ejemplo, una partición definida usando FROM (MINVALUE) TO (10) permite cualquier valor menor que 10, y una partición definida usando FROM (10) TO (MAXVALUE) permite cualquier valor mayor o igual a 10.

Al crear una partición por rango que involucra más de una columna, también puede tener sentido utilizar MAXVALUE como parte del límite inferior, y MINVALUE como parte del límite superior. Por ejemplo, una partición definida usando FROM (0, MAXVALUE) TO (10, MAXVALUE) permite cualquier fila donde la primera columna de la clave de partición sea mayor que 0 y menor o igual a 10. Del mismo modo, una partición definida usando FROM ('a', MINVALUE) TO ('b', MINVALUE) permite cualquier fila donde la primera columna de la clave de partición comience con "a".

Ten en cuenta que si se utiliza MINVALUE o MAXVALUE para una columna de un límite de particionamiento, se debe utilizar el mismo valor para todas las columnas siguientes. Por ejemplo, (10, MINVALUE, 0) no es un límite válido; debes escribir (10, MINVALUE, MINVALUE).

También ten en cuenta que algunos tipos de elementos, como timestamp, tienen una noción de "infinito", que es simplemente otro valor que se puede almacenar. Esto es diferente de MINVALUE y MAXVALUE, que no son valores reales que se puedan almacenar, sino formas de decir que el valor no tiene límites. Se puede pensar en MAXVALUE como mayor que cualquier otro valor, incluido "infinito", y en MINVALUE como menor que cualquier otro valor, incluido "menos infinito". Así, el rango FROM ('infinity') TO (MAXVALUE) no es un rango vacío; permite almacenar exactamente un valor: "infinito".

Si se especifica DEFAULT, la tabla se creará como la partición por defecto de la tabla padre. Esta opción no está disponible para tablas particionadas por hash. Un valor de clave de partición que no encaje en ninguna otra partición del padre dado se enrutará a la partición por defecto.

Cuando una tabla tiene una partición DEFAULT existente y se le añade una nueva partición, la partición por defecto debe escanearse para verificar que no contiene ninguna fila que corresponda propiamente a la nueva partición. Si la partición por defecto contiene un gran número de filas, esto puede ser lento. El escaneo se omitirá si la partición por defecto es una tabla foránea o si tiene una restricción que demuestre que no puede contener filas que deban colocarse en la nueva partición.

Al crear una partición hash, se debe especificar un módulo y un resto. El módulo debe ser un entero positivo y el resto debe ser un entero no negativo menor que el módulo. Normalmente, al configurar inicialmente una tabla particionada por hash, debes elegir un módulo igual al número de particiones y asignar a cada tabla el mismo módulo y un resto diferente (consulta los ejemplos más abajo). Sin embargo, no es necesario que cada partición tenga el mismo módulo, solo que cada módulo que ocurra entre las particiones de una tabla particionada por hash sea un factor del siguiente módulo más grande. Esto permite aumentar el número de particiones de forma incremental sin necesidad de mover todos los datos a la vez. Por ejemplo, supón que tienes una tabla particionada por hash con 8 particiones, cada una de las cuales tiene un módulo de 8, pero consideras necesario aumentar el número de particiones a 16. Puedes desacoplar una de las particiones con módulo 8, crear dos nuevas particiones con módulo 16 que cubran la misma parte del espacio de claves (una con un resto igual al resto de la partición desacoplada y la otra con un resto igual a ese valor más 8), y volver a llenarlas con datos. Luego puedes repetir esto, tal vez más adelante, para cada partición con módulo 8 hasta que no quede ninguna. Aunque esto todavía puede implicar un gran movimiento de datos en cada paso, sigue siendo mejor que tener que crear una tabla completamente nueva y mover todos los datos a la vez.

Una partición debe tener los mismos nombres y tipos de columnas que la tabla particionada a la que pertenece. Las modificaciones en los nombres o tipos de columna de una tabla particionada se propagarán automáticamente a todas sus particiones. Las restricciones CHECK serán heredadas automáticamente por cada partición, pero una partición individual puede especificar restricciones CHECK adicionales; las restricciones adicionales con el mismo nombre y condición que en el padre se fusionarán con la restricción del padre. Los valores por defecto se pueden especificar por separado para cada partición. Pero ten en cuenta que el valor por defecto de una partición no se aplica al insertar una fila a través de una tabla particionada.

Las filas insertadas en una tabla particionada se enrutarán automáticamente a la partición correcta. Si no existe una partición adecuada, se producirá un error.

Las operaciones como TRUNCATE que normalmente afectan a una tabla y a todos sus hijos heredados se aplicarán en cascada a todas las particiones, pero también se pueden realizar en una partición individual.

Ten en cuenta que la creación de una partición mediante PARTITION OF requiere adquirir un bloqueo ACCESS EXCLUSIVE en la tabla particionada padre. Del mismo modo, la eliminación de una partición con DROP TABLE requiere adquirir un bloqueo ACCESS EXCLUSIVE en la tabla padre. Es posible utilizar ALTER TABLE ATTACH/DETACH PARTITION para realizar estas operaciones con un bloqueo más débil, reduciendo así la interferencia con operaciones concurrentes en la tabla particionada.

La cláusula LIKE especifica una tabla de la cual la nueva tabla copia automáticamente todos los nombres de columna, sus tipos de datos y sus restricciones de no nulidad.

A diferencia de INHERITS, la nueva tabla y la tabla original quedan completamente desacopladas una vez finalizada la creación. Los cambios en la tabla original no se aplicarán a la nueva tabla, y no es posible incluir datos de la nueva tabla en los escaneos de la tabla original.

También a diferencia de INHERITS, las columnas y restricciones copiadas por LIKE no se fusionan con columnas y restricciones de nombre similar. Si se especifica el mismo nombre explícitamente o en otra cláusula LIKE, se señala un error.

Las cláusulas opcionales opción_like especifican qué propiedades adicionales de la tabla original se deben copiar. Especificar INCLUDING copia la propiedad, mientras que especificar EXCLUDING la omite. EXCLUDING es el comportamiento por defecto. Si se realizan varias especificaciones para el mismo tipo de objeto, se utiliza la última. Las opciones disponibles son:

La cláusula LIKE también se puede usar para copiar definiciones de columna de vistas, tablas foráneas o tipos compuestos. Las opciones inaplicables (por ejemplo, INCLUDING INDEXES de una vista) se ignoran.

Un nombre opcional para una restricción de columna o tabla. Si se viola la restricción, el nombre de la restricción está presente en los mensajes de error, por lo que se pueden utilizar nombres de restricción como col must be positive para comunicar información útil sobre la restricción a las aplicaciones cliente. (Se necesitan comillas dobles para especificar nombres de restricción que contengan espacios). Si no se especifica un nombre de restricción, el sistema genera uno.

La columna no puede contener valores nulos.

Una restricción marcada con NO INHERIT no se propagará a las tablas hijas.

La columna puede contener valores nulos. Este es el comportamiento por defecto.

Esta cláusula se proporciona únicamente para compatibilidad con bases de datos SQL no estándar. Se desaconseja su uso en nuevas aplicaciones.

La cláusula CHECK especifica una expresión que produce un resultado booleano que las filas nuevas o actualizadas deben cumplir para que una operación de inserción o actualización tenga éxito. Las expresiones que evalúan a TRUE o UNKNOWN tienen éxito. Si alguna fila de una operación de inserción o actualización produce un resultado FALSE, se genera una excepción de error y la inserción o actualización no altera la base de datos. Una restricción de verificación especificada como una restricción de columna debe hacer referencia únicamente al valor de esa columna, mientras que una expresión que aparece en una restricción de tabla puede hacer referencia a varias columnas.

Actualmente, las expresiones CHECK no pueden contener subconsultas ni hacer referencia a variables que no sean columnas de la fila actual (consulta Section 5.5.1). Se puede hacer referencia a la columna del sistema tableoid, pero no a ninguna otra columna del sistema.

Una restricción marcada con NO INHERIT no se propagará a las tablas hijas.

Cuando una tabla tiene varias restricciones CHECK, se probarán para cada fila en orden alfabético por nombre, después de verificar las restricciones NOT NULL. (Las versiones de PostgreSQL anteriores a la 9.5 no respetaban ningún orden de ejecución particular para las restricciones CHECK).

La cláusula DEFAULT asigna un valor de datos por defecto para la columna en cuya definición aparece. El valor es cualquier expresión libre de variables (en particular, no se permiten referencias cruzadas a otras columnas de la tabla actual). Tampoco se permiten subconsultas. El tipo de datos de la expresión por defecto debe coincidir con el tipo de datos de la columna.

La expresión por defecto se utilizará en cualquier operación de inserción que no especifique un valor para la columna. Si no hay un valor por defecto para una columna, el valor por defecto es nulo.

Esta cláusula crea la columna como una columna generada. No se puede escribir en la columna, y al leerla se devolverá el resultado de la expresión especificada.

Cuando se especifica VIRTUAL, la columna se calculará cuando se lea y no ocupará almacenamiento. Cuando se especifica STORED, la columna se calculará en la escritura y se almacenará en el disco. VIRTUAL es el comportamiento por defecto.

La expresión de generación puede hacer referencia a otras columnas de la tabla, pero no a otras columnas generadas. Todas las funciones y operadores utilizados deben ser inmutables. No se permiten referencias a otras tablas.

Una columna generada virtual no puede tener un tipo definido por el usuario, y la expresión de generación de una columna generada virtual no debe hacer referencia a funciones o tipos definidos por el usuario, es decir, solo puede usar funciones o tipos incorporados. Esto se aplica también indirectamente, como para funciones o tipos que subyacen a operadores o conversiones (casts). (Esta restricción no existe para las columnas generadas almacenadas).

Esta cláusula crea la columna como una columna de identidad. Tendrá una secuencia implícita asociada y, en las filas recién insertadas, la columna tendrá automáticamente valores asignados a partir de esa secuencia. Dicha columna es implícitamente NOT NULL.

Las cláusulas ALWAYS y BY DEFAULT determinan cómo se manejan los valores especificados explícitamente por el usuario en los comandos INSERT y UPDATE.

En un comando INSERT, si se selecciona ALWAYS, se acepta un valor especificado por el usuario solo si la sentencia INSERT especifica OVERRIDING SYSTEM VALUE. Si se selecciona BY DEFAULT, el valor especificado por el usuario tiene prioridad. Consulta INSERT para obtener detalles. (En el comando COPY, los valores especificados por el usuario siempre se utilizan independientemente de esta configuración).

En un comando UPDATE, si se selecciona ALWAYS, se rechazará cualquier actualización de la columna a cualquier valor que no sea DEFAULT. Si se selecciona BY DEFAULT, la columna se puede actualizar normalmente. (No hay una cláusula OVERRIDING para el comando UPDATE).

La cláusula opcional opciones_secuencia se puede utilizar para anular los parámetros de la secuencia. Las opciones disponibles incluyen las que se muestran para CREATE SEQUENCE, más SEQUENCE NAME nombre, LOGGED y UNLOGGED, que permiten la selección del nombre y el nivel de persistencia de la secuencia. Sin SEQUENCE NAME, el sistema elige un nombre no utilizado para la secuencia. Sin LOGGED o UNLOGGED, la secuencia tendrá el mismo nivel de persistencia que la tabla.

La restricción UNIQUE especifica que un grupo de una o más columnas de una tabla puede contener únicamente valores únicos. El comportamiento de una restricción de tabla única es el mismo que el de una restricción de columna única, con la capacidad adicional de abarcar varias columnas. Por lo tanto, la restricción exige que dos filas cualesquiera difieran en al menos una de estas columnas.

Si se especifica la opción WITHOUT OVERLAPS para la última columna, se comprueba que esa columna no tenga superposiciones en lugar de comprobar la igualdad. En ese caso, las otras columnas de la restricción permitirán duplicados siempre que los duplicados no se superpongan en la columna WITHOUT OVERLAPS. (A esto a veces se le llama clave temporal, si la columna es un rango de fechas o marcas de tiempo, pero PostgreSQL permite rangos sobre cualquier tipo base). En efecto, tal restricción se aplica con una restricción EXCLUDE en lugar de una restricción UNIQUE. Por ejemplo, UNIQUE (id, valid_at WITHOUT OVERLAPS) se comporta como EXCLUDE USING GIST (id WITH =, valid_at WITH &&). La columna WITHOUT OVERLAPS debe tener un tipo de rango o multirango. No se permiten rangos o multirangos vacíos. Las columnas que no son WITHOUT OVERLAPS de la restricción pueden ser de cualquier tipo que se pueda comparar por igualdad en un índice GiST. Por defecto, solo se admiten tipos de rango, pero puedes usar otros tipos agregando la extensión btree_gist (que es la forma esperada de usar esta característica).

A efectos de una restricción única, los valores nulos no se consideran iguales, a menos que se especifique NULLS NOT DISTINCT.

Cada restricción única debe nombrar un conjunto de columnas que sea diferente del conjunto de columnas nombrado por cualquier otra restricción única o de clave primaria definida para la tabla. (De lo contrario, las restricciones únicas redundantes se descartarán).

Al establecer una restricción única para una jerarquía de particiones de varios niveles, todas las columnas de la clave de partición de la tabla particionada objetivo, así como las de todas sus tablas particionadas descendientes, deben incluirse en la definición de la restricción.

Agregar una restricción única creará automáticamente un índice btree único en la columna o grupo de columnas utilizado en la restricción. Pero si la restricción incluye una cláusula WITHOUT OVERLAPS, utilizará un índice GiST. El índice creado tiene el mismo nombre que la restricción única.

La cláusula opcional INCLUDE agrega a ese índice una o más columnas que son simplemente “carga útil” (payload): no se exige unicidad sobre ellas, y el índice no se puede buscar sobre la base de esas columnas. Sin embargo, se pueden recuperar mediante un escaneo solo de índice (index-only scan). Ten en cuenta que aunque la restricción no se aplica a las columnas incluidas, sigue dependiendo de ellas. En consecuencia, algunas operaciones en tales columnas (por ejemplo, DROP COLUMN) pueden causar la eliminación en cascada de la restricción y del índice.

La restricción PRIMARY KEY especifica que una columna o columnas de una tabla pueden contener únicamente valores únicos (no duplicados) y no nulos. Solo se puede especificar una clave primaria para una tabla, ya sea como una restricción de columna o como una restricción de tabla.

La restricción de clave primaria debe nombrar un conjunto de columnas que sea diferente del conjunto de columnas nombrado por cualquier restricción única definida para la misma tabla. (De lo contrario, la restricción única es redundante y se descartará).

PRIMARY KEY impone las mismas restricciones de datos que una combinación de UNIQUE y NOT NULL. Sin embargo, identificar un conjunto de columnas como clave primaria también proporciona metadatos sobre el diseño del esquema, ya que una clave primaria implica que otras tablas pueden confiar en este conjunto de columnas como identificador único para las filas.

Cuando se colocan en una tabla particionada, las restricciones PRIMARY KEY comparten las restricciones descritas anteriormente para las restricciones UNIQUE.

Agregar una restricción PRIMARY KEY creará automáticamente un índice btree único en la columna o grupo de columnas utilizado en la restricción, o GiST si se especificó WITHOUT OVERLAPS.

La cláusula opcional INCLUDE agrega a ese índice una o más columnas que son simplemente “carga útil” (payload): no se exige unicidad sobre ellas, y el índice no se puede buscar sobre la base de esas columnas. Sin embargo, se pueden recuperar mediante un escaneo solo de índice. Ten en cuenta que aunque la restricción no se aplica a las columnas incluidas, sigue dependiendo de ellas. En consecuencia, algunas operaciones en tales columnas (por ejemplo, DROP COLUMN) pueden causar la eliminación en cascada de la restricción y del índice.

La cláusula EXCLUDE define una restricción de exclusión, que garantiza que si se comparan dos filas cualesquiera en las columnas o expresiones especificadas utilizando los operadores especificados, no todas estas comparaciones devolverán TRUE. Si todos los operadores especificados prueban la igualdad, esto es equivalente a una restricción UNIQUE, aunque una restricción única ordinaria será más rápida. Sin embargo, las restricciones de exclusión pueden especificar restricciones que son más generales que la simple igualdad. Por ejemplo, puedes especificar una restricción de que no haya dos filas en la tabla que contengan círculos superpuestos (consulta Section 8.8) utilizando el operador &&. Los operadores deben ser conmutativos.

Las restricciones de exclusión se implementan utilizando un índice que tiene el mismo nombre que la restricción, por lo que cada operador especificado debe estar asociado con una clase de operador adecuada (consulta Section 11.10) para el método de acceso al índice método_índice. Cada elemento_exclusión define una columna del índice, por lo que opcionalmente puede especificar una ordenación, una clase de operador, parámetros de clase de operador y/o opciones de ordenación; estos se describen detalladamente en CREATE INDEX.

El método de acceso debe admitir amgettuple (consulta Chapter 63); en la actualidad esto significa que no se puede usar GIN. Aunque está permitido, tiene poco sentido usar índices B-tree o hash con una restricción de exclusión, porque esto no hace nada que una restricción única ordinaria no haga mejor. Por lo tanto, en la práctica el método de acceso siempre será GiST o SP-GiST.

El predicado permite especificar una restricción de exclusión en un subconjunto de la tabla; internamente esto crea un índice parcial. Ten en cuenta que se requieren paréntesis alrededor del predicado.

Al establecer una restricción de exclusión para una jerarquía de particiones de varios niveles, todas las columnas de la clave de partición de la tabla particionada objetivo, así como las de todas sus tablas particionadas descendientes, deben incluirse en la definición de la restricción. Además, esas columnas deben compararse utilizando el operador de igualdad. Estas restricciones garantizan que las filas potencialmente conflictivas existan en la misma partición. La restricción también puede hacer referencia a otras columnas que no forman parte de ninguna clave de partición, las cuales se pueden comparar utilizando cualquier operador adecuado.

Estas cláusulas especifican una restricción de clave foránea, que requiere que un grupo de una o más columnas de la nueva tabla contenga únicamente valores que coincidan con los valores en las columnas referenciadas de alguna fila de la tabla referenciada. Si se omite la lista de columnas referenciadas (columna_ref), se utiliza la clave primaria de la tabla referenciada (tabla_ref). De lo contrario, la lista de columnas referenciadas debe referirse a las columnas de una restricción de clave primaria o única no diferible o ser las columnas de un índice único no parcial.

Si la última columna está marcada con PERIOD, se trata de una manera especial. Mientras que las columnas que no son PERIOD se comparan por igualdad (y debe haber al menos una de ellas), la columna PERIOD no se compara de esa forma. En su lugar, la restricción se considera satisfecha si la tabla referenciada tiene registros coincidentes (basados en las partes de la clave que no son PERIOD) cuyos valores de PERIOD combinados cubren por completo los del registro que hace la referencia. En otras palabras, la referencia debe tener un referente para toda su duración. Esta columna debe ser de tipo rango o multirango. Además, la tabla referenciada debe tener una clave primaria o restricción única declarada con WITHOUT OVERLAPS. Finalmente, si la clave foránea tiene una especificación nombre_columna marcada con PERIOD, la correspondiente columna_ref, si está presente, también debe estar marcada como PERIOD. Si se omite la cláusula de la columna referenciada y por lo tanto se elige la restricción de clave primaria de la tabla referenciada, la clave primaria debe tener su columna final marcada como WITHOUT OVERLAPS.

Para cada par de columnas que hace la referencia y columna referenciada, si son de un tipo de datos ordenable, las ordenaciones deben ser ambas deterministas o, de lo contrario, ambas iguales. Esto garantiza que ambas columnas tengan una noción coherente de la igualdad.

El usuario debe tener el permiso REFERENCES en la tabla referenciada (ya sea en toda la tabla o en las columnas referenciadas específicas). La adición de una restricción de clave foránea requiere un bloqueo SHARE ROW EXCLUSIVE en la tabla referenciada. Ten en cuenta que las restricciones de clave foránea no se pueden definir entre tablas temporales y tablas permanentes.

Un valor insertado en las columnas que hacen la referencia se compara con los valores de la tabla referenciada y las columnas referenciadas utilizando el tipo de coincidencia dado. Hay tres tipos de coincidencia: MATCH FULL, MATCH PARTIAL y MATCH SIMPLE (que es el comportamiento por defecto). MATCH FULL no permitirá que una columna de una clave foránea de varias columnas sea nula a menos que todas las columnas de la clave foránea sean nulas; si todas son nulas, no se requiere que la fila tenga una coincidencia en la tabla referenciada. MATCH SIMPLE permite que cualquiera de las columnas de la clave foránea sea nula; si alguna de ellas es nula, no se requiere que la fila tenga una coincidencia en la tabla referenciada. MATCH PARTIAL aún no está implementado. (Por supuesto, se pueden aplicar restricciones NOT NULL a las columnas que hacen la referencia para evitar que surjan estos casos).

Además, cuando se cambian los datos en las columnas referenciadas, se realizan ciertas acciones en los datos de las columnas de esta tabla. La cláusula ON DELETE especifica la acción a realizar cuando se elimina una fila referenciada en la tabla referenciada. Del mismo modo, la cláusula ON UPDATE especifica la acción a realizar cuando una columna referenciada en la tabla referenciada se actualiza a un nuevo valor. Si la fila se actualiza, pero la columna referenciada no cambia realmente, no se realiza ninguna acción. Las acciones referenciales se ejecutan como parte del comando de cambio de datos, incluso si la restricción está diferida. Existen las siguientes acciones posibles para cada cláusula:

Si las columnas referenciadas cambian con frecuencia, podría ser aconsejable agregar un índice a las columnas que hacen la referencia para que las acciones referenciales asociadas con la restricción de clave foránea se puedan realizar de manera más eficiente.

Esto controla si la restricción se puede diferir. Una restricción que no es diferible se verificará inmediatamente después de cada comando. La verificación de las restricciones que son diferibles se puede posponer hasta el final de la transacción (utilizando el comando SET CONSTRAINTS). NOT DEFERRABLE es el comportamiento por defecto. Actualmente, solo las restricciones UNIQUE, PRIMARY KEY, EXCLUDE y REFERENCES (clave foránea) aceptan esta cláusula. Las restricciones NOT NULL y CHECK no son diferibles. Ten en cuenta que las restricciones diferibles no se pueden utilizar como árbitros de conflictos en una sentencia INSERT que incluya una cláusula ON CONFLICT.

Si una restricción es diferible, esta cláusula especifica el momento por defecto para verificar la restricción. Si la restricción es INITIALLY IMMEDIATE, se verifica después de cada sentencia. Este es el comportamiento por defecto. Si la restricción es INITIALLY DEFERRED, se verifica solo al final de la transacción. El momento de verificación de la restricción se puede alterar con el comando SET CONSTRAINTS.

Cuando la restricción es ENFORCED, el sistema de base de datos garantizará que la restricción se cumpla, verificando la restricción en los momentos adecuados (después de cada sentencia o al final de la transacción, según corresponda). Ese es el comportamiento por defecto. Si la restricción es NOT ENFORCED, el sistema de base de datos no verificará la restricción. Corresponde entonces al código de la aplicación garantizar que se cumplan las restricciones. El sistema de base de datos aún podría asumir que los datos realmente cumplen con la restricción para decisiones de optimización en las que esto no afecte la corrección del resultado.

Las restricciones NOT ENFORCED pueden ser útiles como documentación si la verificación real de la restricción en tiempo de ejecución es demasiado costosa.

Actualmente esto solo se admite para restricciones de clave foránea y CHECK.

Esta cláusula opcional especifica el método de acceso a la tabla a utilizar para almacenar los contenidos de la nueva tabla; el método debe ser un método de acceso de tipo TABLE. Consulta Chapter 62 para obtener más información. Si no se especifica esta opción, se elige el método de acceso a la tabla por defecto para la nueva tabla. Consulta default_table_access_method para obtener más información.

Al crear una partición, el método de acceso a la tabla es el método de acceso de su tabla particionada, si está establecido.

Esta cláusula especifica parámetros de almacenamiento opcionales para una tabla o índice; consulta Parámetros de almacenamiento más abajo para obtener más información. Para compatibilidad con versiones anteriores, la cláusula WITH para una tabla también puede incluir OIDS=FALSE para especificar que las filas de la nueva tabla no deben contener OID (identificadores de objeto), OIDS=TRUE ya no está admitido.

Esta es una sintaxis compatible con versiones anteriores para declarar una tabla WITHOUT OIDS, ya no está admitido crear una tabla con OID (WITH OIDS).

El comportamiento de las tablas temporales al final de un bloque de transacción se puede controlar mediante ON COMMIT. Las tres opciones son:

El nombre_tablespace es el nombre del tablespace en el que se va a crear la nueva tabla. Si no se especifica, se consulta default_tablespace, o temp_tablespaces si la tabla es temporal. Para las tablas particionadas, dado que no se requiere almacenamiento para la tabla en sí, el tablespace especificado anula default_tablespace como el tablespace por defecto a utilizar para cualquier partición recién creada cuando no se especifica explícitamente otro tablespace.

Esta cláusula permite seleccionar el tablespace en el que se creará el índice asociado a una restricción UNIQUE, PRIMARY KEY o EXCLUDE. Si no se especifica, se consulta default_tablespace, o temp_tablespaces si la tabla es temporal.