La table est temporaire. Les tables temporaires sont automatiquement supprimées à la fin d'une session ou, optionnellement, à la fin de la transaction en cours (voir ON COMMIT ci-dessous). Les tables permanentes qui portent le même nom ne sont pas visibles dans la session courante tant que la table temporaire existe sauf s'il y est fait référence par leur nom qualifié du schéma. Tous les index créés sur une table temporaire sont automatiquement temporaires.

Le démon autovacuum ne peut pas accéder et, du coup, ne peut pas exécuter un VACUUM ou un ANALYZE sur les tables temporaires. Pour cette raison, les opérations VACUUM et ANALYZE doivent être traitées via des commandes SQL de session. Par exemple, si une table temporaire doit être utilisée dans des requêtes complexes, il est raisonnable d'exécuter ANALYZE sur la table temporaire après qu'elle ait été peuplée.

On peut éventuellement écrire GLOBAL ou LOCAL avant TEMPORARY ou TEMP. Cela ne fait pas de différence dans PostgreSQL (cf. Cela ne fait actuellement pas de différence dans PostgreSQL et est obsolète ; voir Compatibilité).

Si spécifié, la table est créée en tant que table non tracée. Les données écrites dans ce type de table ne sont pas écrites dans les journaux de transactions (voir Chapitre 29), ce qui les rend considérablement plus rapides que les tables ordinaires. Néanmoins, elles ne sont pas sûres en cas d'arrêt brutal : une table non tracée est automatiquement vidée après un arrêt brutal. Le contenu d'une table non tracée n'est pas répliqué vers les serveurs en attente. Tout index créé sur une table non tracée est aussi automatiquement non tracé.

N'affiche pas d'erreur si une relation de même nom existe déjà. Un message de niveau notice est retourné dans ce cas. Notez qu'il n'existe aucune garantie que la relation existante ressemble à celle qui devait être créée..

Le nom (éventuellement qualifié du nom du schéma) de la table à créer.

Crée une table typée, qui prend sa structure à partir du type composite spécifié (son nom peut être qualifié du schéma). Une table typée est liée à son type ; par exemple, la table sera supprimée si le type est supprimé (avec DROP TYPE ... CASCADE).

Quand une table typée est créée, les types de données des colonnes sont déterminés par le type composite sous-jacent et ne sont pas indiqués par la commande CREATE TABLE. Mais la commande CREATE TABLE peut ajouter des valeurs par défaut et des contraintes à la table. Elle peut aussi indiquer des paramètres de stockage.

Le nom d'une colonne de la nouvelle table.

Le type de données de la colonne. Cela peut inclure des spécificateurs de tableaux. Pour plus d'informations sur les types de données supportés par PostgreSQL, on se référera à Chapitre 8.

La clause COLLATE affecte un collationnement à une colonne (qui doit être d'un type de données collationnable). Sans information, le collationnement par défaut du type de données de la colonne est utilisé.

La clause optionnelle INHERITS indique une liste de tables dont les colonnes sont automatiquement héritées par la nouvelle table. Les tables parents peuvent être des tables standards ou des tables distantes.

L'utilisation d'INHERITS crée une relation persistante entre la nouvelle table enfant et sa table parent. Les modifications de schéma du(des) parent(s) se propagent normalement aux enfants et, par défaut, les données de la table enfant sont incluses dans les parcours de(s) parent(s).

Si un même nom de colonne existe dans plusieurs tables parentes, une erreur est rapportée, à moins que les types de données des colonnes ne correspondent dans toutes les tables parentes. S'il n'y a pas de conflit, alors les colonnes dupliquées sont assemblées pour former une seule colonne dans la nouvelle table. Si la liste des noms de colonnes de la nouvelle table contient un nom de colonne hérité, le type de données doit correspondre à celui des colonnes héritées et les définitions des colonnes sont fusionnées. Si la nouvelle table spécifie explicitement une valeur par défaut pour la colonne, cette valeur surcharge toute valeur par défaut héritée. Dans le cas contraire, les parents qui spécifient une valeur par défaut doivent tous spécifier la même, sans quoi une erreur est rapportée.

Les contraintes CHECK sont fusionnées, dans les grandes lignes, de la même façon que les colonnes : si des tables parentes multiples et/ou la nouvelle définition de table contient des contraintes CHECK de même nom, ces contraintes doivent toutes avoir la même expression de vérification, ou une erreur sera retournée. Les contraintes qui ont le même nom et la même expression seront fusionnées en une seule. Une contrainte marquée NO INHERIT dans une table parent ne sera pas prise en compte. Notez qu'une contrainte CHECK non nommée dans la nouvelle table ne sera jamais fusionnée puisqu'un nom unique lui sera toujours affecté.

Les paramètres STORAGE de la colonne sont aussi copiés des tables parents.

Si une colonne de la table parente est une colonne d'identité, cette propriété n'est pas héritée. Une colone dans la table enfant peut être déclarée comme colonne d'identité si l'on veut.

La clause facultative PARTITION BY spécifie une statégie pour partitionner la table. La table ainsi crée est appelée table partitionnée. La liste de colonnes ou d'expressions entre parenthèses forme la clé de partitionnement de la table. Quand un partitionnement par intervalle ou hachage est utilisé, la clé de partitionnement peut inclure de multiples colonnes ou expressions (jusqu'à 32, mais cette limite peut être modifiée lors de la compilation de PostgreSQL.), mais pour le partitionnement par liste, la clé de partitionnement doit être constituée d'une seule colonne ou expression.

Les partitionnements par intervalle ou par liste nécessitent une classe d'opérateur btree, alors que le partitionnement par hachage exige une classe d'opérateur hash. Si aucune classe d'opérateur n'est précisée explicitement, la classe d'opérateur par défaut du type approprié sera utilisée ; si aucune classe d'opérateur n'existe, une erreur sera levée. Si le partitionnement par hachage est utilisé, la classe d'opérateur utilisée doit implémenter la fonction de support 2 (voir Section 37.16.3 pour les détails).

Une table partitionnée est divisée en sous tables (appelées partitions), qui sont créées en utilisant des commandes CREATE TABLE séparées. La table partitionnée est elle-même vide. Une ligne de données insérée dans la table est redirigée vers une partition en fonction de la valeur des colonnes ou expressions de la clé de partitionnement. S'il n'existe pas de partition correspondant aux valeurs de la nouvelle ligne, une erreur sera levée.

Les tables partitionnées ne supportent pas les contraintes EXCLUDE ; cependant vous pouvez définir ces contraintes sur des partitions individuelles.

Voir Section 5.11 pour plus de détails sur le partitionnement des tables.

Crée la table comme une partition de la table parente spécifiée. La table peut être créée, soit comme une partition pour des valeurs spécifiques avec FOR VALUES, soit comme la partition par défaut avec DEFAULT. Tout index, toute contrainte et tout trigger de niveau ligne défini par l'utilisateur existant dans la table parent est clonée sur la nouvelle partition.

Le paramètre spec_limites_partition doit correspondre à la méthode et à la clé de partitionnement de la table parent, et ne doit pas déborder sur toute partition existante du parent. La forme avec IN est utilisée pour le partitionnement de liste, la forme avec FROM et TO est utilisée pour le partitionnement par intervalles, et la forme avec WITH est utilisée pour le partitionnement par hachage.

expr_limite_partition peut être n'importe quelle expression sans variable (les sous-requêtes, fonctions de fenêtrage, fonctions d'aggrégation ou toute fonction renvoyant une relation ne sont pas autorisées). Son type de donnée doit être le même que celui de la clé de partitionnement. L'expression étant évaluée une seule fois, au moment de la création de la table, il est possible d'utiliser des expressions volatiles comme CURRENT_TIMESTAMP .

Lors de la création d'une partition en liste, NULL peut être indiquer pour signifier que la partition permet à la colonne de clé de partitionnement d'être NULL. Néanmoins, il ne peut y avoir plus d'une partition de ce type pour une table parent donnée. NULL n'est pas accepté pour les partitions par intervalle.

Lorsqu'une partition de type intervalle est créée, la borne inférieure spécifiée avec FROM est une borne inclusive, alors que la borne supérieure spécifiée avec TO est une borne exclusive. C'est-à-dire que les valeurs spécifiées dans la liste FROM sont des valeurs valides des colonnes correspondantes de la clé de partitionnement pour cette partition, alors que celles dans la liste TO ne le sont pas. Notez que ceci doit être compris suivant les règles de la comparaison de lignes (Section 9.24.5). Par exemple, étant donné PARTITION BY RANGE (x,y), une limite de partition FROM (1, 2) TO (3, 4) permet x=1 pour tout y>=2, x=2 avec tout y non NULL, et x=3 avec tout y<4.

Les valeurs spéciales MINVALUE et MAXVALUE peuvent être utilisées lors de la création d'une partition par intervalles pour indiquer qu'il n'y a pas de limite basse ou haute sur la valeur de la colonne. Par exemple, une partition définie comme utilisant FROM (MINVALUE) TO (10) accepte toutes les valeurs inférieures à 10, et une partition définie en utilisant FROM (10) TO (MAXVALUE) accepte toutes les valeurs supérieures ou égales à 10.

Lors de la création d'une partition par intervalles impliquant plus d'une colonne, il est aussi sensé d'utiliser MAXVALUE comme élément de la limite basse et MINVALUE comme élément de limite haute. Par exemple, une partition définie en utilisant FROM (0, MAXVALUE) TO (10, MAXVALUE) accepte toute ligne où la première colonne de la clé de partitionnement est supérieure à zéro et inférieure ou égale à dix. De la même façon, une partition définie en utilisant FROM ('a', MINVALUE) TO ('b', MINVALUE) accepte toute ligne où la première colonne de la clé de partitionnement commence avec la lettre a.

Notez que si MINVALUE ou MAXVALUE est utilisé pour une colonne d'une limite de partitionnement, la même valeur doit être utilisée pour toutes les colonnes suivantes. Par exemple, (10, MINVALUE, 0) n'est pas une limite valide. Vous devriez écrire (10, MINVALUE, MINVALUE).

De plus, notez que certains types d'éléments, tels que timestamp, ont une notion d'infinité, qui est simplement une autre valeur qui peut être enregistré. Ceci est différent de MINVALUE et MAXVALUE, qui ne sont pas de vraies valeurs pouvant être enregistrées, mais plutôt une façon de dire que la valeur est sans limite. MAXVALUE peut être vu comme étant supérieur à toute autre valeur, ceci incluant infinity et MINVALUE comme étant inférieure à toute autre valeur, ceci incluant moins infinity. De ce fait, l'intervalle FROM ('infinity') TO (MAXVALUE) n'est pas un intervalle vide. Il autorise le stockage d'une seule valeur -- "infinity".

Quand une partition par liste de valeurs est créée, NULL peut être spécifié pour dire que la partition autorise la colonne de la clé de partitionnement à être NULL. Cepdnant, il ne peut pas y avoir plus d'une partition par liste de ce type pour une même table parente. NULL ne peut pas être utilisé pour les partitions par intervalles.

Si DEFAULT est spécifié, la table sera créée comme la partition par défaut de la table parente. Celle option n'est pas disponible pour les tables partitionnées par hachage. Une clé de partition qui ne passe dans aucune autre partition de la table parente sera orientée vers la partition par défaut.

Si une table possède une partition DEFAULT et qu'on lui ajoute une nouvelle partition, la partition par défaut doit être parcourue pour vérifier qu'elle ne contient aucune ligne qui appartient normalement à la nouvelle partition. Si la partition par défaut contient un grand nombre de lignes, cela peut être long. Ce parcours peut être évité si la partition par défaut est une table étrangère ou possède une contrainte prouvant qu'elle ne peut contenir des lignes qui devraient appartenir à la nouvelle partition.

À la création d'une partition par hachage, un diviseur et un reste doivent être spécifiés. Le diviseur doit être un entier positif, et le reste un entier non négatif inférieur au diviseur. Typiquement, au début de la mise en place d'un partitionnement par hachage, vous devrez choisir un diviseur égal au nombre de partitions et assigner à chaque table le même diviseur et un reste différent (voir les exemples plus bas). Cependant, il n'est pas obligatoire que chaque partition ait le même diviseur, juste que chaque diviseur apparaissant dans une table partitionnée par hachage soit un facteur du diviseur immédiatement supérieur. Cela permet d'augmenter le nombre de partitions de manière incrémentale sans avoir besoin de déplacer toutes les données d'un coup. Par exemple, supposons que vous ayez une table partitionnée par hachage avec 8 partitions, toutes de diviseur 8, mais que vous trouvez qu'il faille augmenter le nombre de partitions à 16. Vous pouvez détacher une des partitions de diviseur 8, créer deux nouvelles partitions de diviseur 16 couvrant la même partie de l'espace des clés (une avec un reste égal au reste de la partition détachée, l'autre avec un reste de cette valeur plus 8), et les peupler avec les données. Vous pouvez répéter ceci -- peut-être plus tard -- pour chaque partition de diviseur 8 jusqu'à ce qu'il n'y en ait plus. Bien que cela implique de grands mouvements de données à chaque étape, c'est toujours mieux qu'avoir à créer toute une nouvelle table et d'avoir à déplacer toutes les données en une seule fois.

Une partition doit avoir les mêmes noms de colonne et types de données que la table partitionnée à laquelle elle appartient. Toute modification du type ou du nom d'une colonne d'une table partitionnée sera automatiquement propagée à toutes les partitions. Les contraintes de type CHECK seront automatiquement héritées pour chaque partition, mais il est possible de définir des contraintes de type CHECK supplémentaires sur certaines partitions. Si une contrainte sur une partition porte le même nom qu'une contrainte ajoutée sur la table mère, elle sera fusionnée avec la contrainte de la table parent. Il est possible de définir des valeurs par défaut différentes pour chaque partition. Notez que la valeur par défaut d'une partition ne s'applique pas quand l'insertion de la ligne se fait via la table partitionnée.

Les lignes insérées dans une table partitionnées seront automatiquement redirigées vers la bonne partition. Si aucune des partitions existantes ne convient, une erreur sera levée.

Les opérations telles que TRUNCATE qui n'affectent normalement une table ainsi que tous ses enfants hérités seront cascadées sur toutes les partitions, mais peuvent aussi être effectuées sur une partition individuelle. Veuillez noter que supprimer une partition avec DROP TABLE nécessite de prendre un verrou de type ACCESS EXCLUSIVE sur la table parente.

La clause LIKE spécifie une table à partir de laquelle la nouvelle table copie automatiquement tous les noms de colonnes, leur types de données et les contraintes non NULL.

Contrairement à INHERITS, la nouvelle table et la table originale sont complètement découplées à la fin de la création. Les modifications sur la table originale ne sont pas appliquées à la nouvelle table et les données de la nouvelle table sont pas prises en compte lors du parcours de l'ancienne table.

De plus, contrairement à INHERITS, les colonnes et les contraintes copiées par LIKE ne sont pas assemblées avec des colonnes et des contraintes nommées de façon similaire. Si le même nom est indiqué explicitement ou dans une autre clause LIKE, une erreur est rapportée.

La clause facultative like_option permet de spécifier quelle propriété supplémentaire de la table originale doit être copiée. Spécifier INCLUDING copie la propriété, spécifier EXCLUDING ne copie pas la propriété. EXCLUDING est la valeur par défaut. Si plusieurs clauses INCLUDING et EXCLUDING sont indiquées pour le même type d'objet, la dernière clause est utilisée. Les options disponibles sont :

La clause LIKE peut aussi être utilisée pour copier les définitions de colonne des vues, tables distantes et types composites. Les options inapplicables (comme INCLUDING INDEXES à partir d'une vue) sont ignorées.

Le nom optionnel d'une contrainte de colonne ou de table. Si la contrainte est violée, le nom de la contrainte est présente dans les messages d'erreur. Donc les noms de contraintes comme col doit être positive peut être utilisés pour communiquer des informations utiles aux applications clients. (Des doubles guillemets sont nécessaires pour indiquer les noms des contraintes qui contiennent des espaces.) Si un nom de contrainte n'est pas donné, le système en crée un.

Interdiction des valeurs NULL dans la colonne.

Les valeurs NULL sont autorisées pour la colonne. Comportement par défaut.

Cette clause n'est fournie que pour des raisons de compatibilité avec les bases de données SQL non standard. Son utilisation n'est pas encouragée dans les nouvelles applications.

La clause CHECK spécifie une expression de résultat booléen que les nouvelles lignes ou celles mises à jour doivent satisfaire pour qu'une opération d'insertion ou de mise à jour réussisse. Les expressions de résultat TRUE ou UNKNOWN réussissent. Si une des lignes de l'opération d'insertion ou de mise à jour produit un résultat FALSE, une exception est levée et la base de données n'est pas modifiée. Une contrainte de vérification sur une colonne ne fait référence qu'à la valeur de la colonne tandis qu'une contrainte sur la table fait référence à plusieurs colonnes.

Actuellement, les expressions CHECK ne peuvent ni contenir des sous-requêtes ni faire référence à des variables autres que les colonnes de la ligne courante (voir Section 5.4.1). La colonne système tableoid peut être référencé contrairement aux autres colonnes systèmes.

Une contrainte marquée NO INHERIT ne sera pas propagée aux tables filles.

Quand une table a plusieurs contraintes CHECK, elles seront testées pour chaque ligne dans l'ordre alphabétique de leur nom, après la vérification des contraintes NOT NULL. (Les versions de PostgreSQL antérieures à la 9.5 ne respectaient pas d'ordre de déclenchement particulier pour les contraintes CHECK.)

La clause DEFAULT, apparaissant dans la définition d'une colonne, permet de lui affecter une valeur par défaut. La valeur est une expression libre de variable (en particulier, les références croisées aux autres colonnes de la table courante ne sont pas autorisées). Subqueries are not allowed either. Le type de données de l'expression par défaut doit correspondre au type de données de la colonne.

L'expression par défaut est utilisée dans les opérations d'insertion qui ne spécifient pas de valeur pour la colonne. S'il n'y a pas de valeur par défaut pour une colonne, elle est NULL.

Cette clause crée la colonne comme une colonne générée. La colonne n'est pas accessible en écriture. À la lecture de cette colonne, l'expression spécifiée calculée sera renvoyée.

Le mot-clé STORED est nécessaire pour indiquer que la colonne sera calculée lors de l'écriture et sera stockée sur le disque.

L'expression de génération peut faire référence à d'autres colonnes de la table, mais pas à une autre colonne générée. Toute fonction ou opérateur utilisé dans l'expression de génération devra être IMMUTABLE. Toute référence à d'autres tables est interdite.

Cette clause crée la colonne comme une colonne d'identité. Elle aura une séquence implicite attachée à elle et la colonne dans les nouvelles lignes auront automatiquement des valeurs récupérées de la séquence qui lui est assignée. Une telle colonne est implicitement NOT NULL.

Les clauses ALWAYS et BY DEFAULT déterminent comment la valeur de la séquence est prioritaire par rapport à une valeur définie par l'utilisateur dans un ordre INSERT et UPDATE.

Pour un ordre INSERT, si ALWAYS est spécifié, une valeur définie par l'utilisateur ne sera acceptée que si l'ordre INSERT spécifie OVERRIDING SYSTEM VALUE. Si BY DEFAULT est spécifié, alors la valeur spécifiée par l'utilisateur est prioritaire. Voir INSERT pour plus de détails. (Avec une commande COPY, les valeurs spécifiées par l'utilisateur sont toujours utilisées quelque soit ce paramètre).

Pour un ordre UPDATE, si ALWAYS est spécifié, toute mise à jour de la colonne à une valeur autre que DEFAULT sera rejetée. Si BY DEFAULT est spécifié, la colonne peut être mise à jour normalement. (Il n'y a pas de clause OVERRIDING pour les ordres UPDATE).

La clause facultative options_sequence peut être utilisée pour surcharger les options d'une séquence. Voir CREATE SEQUENCE pour plus de détails.

La contrainte UNIQUE indique qu'un groupe d'une ou plusieurs colonnes d'une table ne peut contenir que des valeurs uniques. Le comportement de la contrainte d'unicité de table est le même que celle de la contrainte d'unicité de colonne, avec la capacité supplémentaire de traiter plusieurs colonnes. Dans ce cas, la contrainte s'assure que tout couple de ligne diffère au moins sur une de ces colonnes.

Pour une contrainte d'unicité, les valeurs NULL ne sont pas considérées comme égales.

Chaque contrainte d'unicité doit nommer un ensemble de colonnes qui est différent de l'ensemble de colonnes nommées par toute autre contrainte d'unicité ou de clé primaire définie pour la table. (Sinon les contraintes d'unicité redondantes seraient ignorées.)

Lors de la mise en place d'une contrainte unique sur une hiérarchie de partitions à plusieurs niveaux, toutes les colonnes de la clé de partitionnement de la table partitionnée cible, ainsi que celles des tables partitionnées filles, doivent être incluses dans la définition de la contrainte.

Ajouter une contrainte d'unicité va automatiquement créer un index btree unique sur la colonne ou le groupe de colonnes utilisée(s) dans la contrainte.

La clause optionnelle INCLUDE ajoute à cet index une ou plusieurs colonnes qui sont uniquement une « charge » : l'unicité n'est pas forcée pour elle, et l'index ne peut pas être utilisé dans une recherche sur ces colonnes. Cependant, elles peuvent être récupérées par un parcours d'index seul. Notez cependant que si la contrainte n'est pas appliquée sur ces colonnes incluses, elle en dépend tout de même. En conséquence, certaines opérations sur ces colonnes (par exemple DROP COLUMN) peuvent causer une suppression en cascade de la contrainte et de l'index.

La contrainte PRIMARY KEY indique qu'une ou plusieurs colonnes d'une table peuvent uniquement contenir des valeurs uniques (pas de valeurs dupliquées) et non NULL. Une table ne peut avoir qu'une seule clé primaire, que ce soit une contrainte au niveau de la colonne ou au niveau de la table.

La contrainte clé primaire doit nommer un ensemble de colonnes différent de l'ensemble de colonnes nommé par toute contrainte unique définie sur la même table. (Sinon, la contrainte unique est redondante et sera ignorée.)

PRIMARY KEY force les mêmes contraintes sur les données que la combinaison UNIQUE et NOT NULL. Néanmoins, identifier un ensemble de colonnes comme une clé primaire fournit aussi des métadonnées sur la conception du schéma car une clé primaire implique que les autres tables peuvent s'appuyer sur cet ensemble de colonnes comme un identifiant unique des lignes de la table.

Lors de leur ajout sur une table partitionnée, les contraintes PRIMARY KEY partagent les restrictions des contraintes UNIQUE précédemment décrites.

Ajouter une contrainte PRIMARY KEY créera automatiquement un index btree d'unicité sur la colonne ou le groupe de colonnes utilisées dans la contrainte.

Ajouter une contrainte PRIMARY KEY va automatiquement créer un index btree unique sur la colonne ou le groupe de colonnes utilisée(s) dans la contrainte.

La clause supplémentaire INCLUDE ajoute à l'index une ou plusieurs colonnes qui sont une simple « charge »: l'unicité n'est pas contrainte pour ces colonnes, et l'index ne peut pas être utilisé sur la base de ces colonnes. Néanmoins, elles peuvent être récupérées par un parcours d'index seul. Notez que, bien que la contrainte n'est pas imposée sur les colonnes incluses, elle dépend des colonnes. En conséquence, certaines opérations sur ces colonnes (par exemple DROP COLUMN) peuvent causer la suppression en cascade de la contrainte et de l'index.

La clause EXCLUDE définit une contrainte d'exclusion qui garantit que si deux lignes sont comparées sur la ou les colonnes spécifiées ou des expressions utilisant le ou les opérateurs spécifiés, seulement certaines de ces comparaisons, mais pas toutes, renverront TRUE. Si tous les opérateurs spécifiés testent une égalité, ceci est équivalent à une contrainte UNIQUE bien qu'une contrainte unique ordinaire sera plus rapide. Néanmoins, ces contraintes d'exclusion peuvent spécifier des contraintes qui sont plus générales qu'une simple égalité. Par exemple, vous pouvez spécifier qu'il n'y a pas deux lignes dans la table contenant des cercles de surcharge (voir Section 8.8) en utilisant l'opérateur &&. Le(s) opérateur(s) doivent être commutatif(s).

Des contraintes d'exclusion sont implantées en utilisant un index, donc chaque opérateur précisé doit être associé avec une classe d'opérateurs appropriée (voir Section 11.10) pour la méthode d'accès par index, nommée méthode_index. Chaque élément_exclusion définit une colonne de l'index, donc il peut spécifier en option une collation, une classe d'opérateur, des paramètres pour la classe d'opérateurs, et/ou des options de tri ; toutes ces options sont décrites entièrement dans CREATE INDEX.

La méthode d'accès doit supporter amgettuple (voir Chapitre 61) ; dès à présent, cela signifie que GIN ne peut pas être utilisé. Bien que cela soit autorisé, il existe peu de raison pour utiliser des index B-tree ou hash avec une contrainte d'exclusion parce que cela ne fait rien de mieux que ce que peut faire une contrainte unique ordinaire. Donc, en pratique, la méthode d'accès sera toujours GiST ou SP-GiST.

Le prédicat vous permet de spécifier une contrainte d'exclusion sur un sous-ensemble de la table ; en interne, un index partiel est créé. Notez que ces parenthèses sont requis autour du prédicat.

Ces clauses spécifient une contrainte de clé étrangère. Cela signifie qu'un groupe de colonnes de la nouvelle table ne peut contenir que des valeurs correspondant à celles des colonnes de référence de la table de référence. Si la liste colonne_reference est omise, la clé primaire de la table_reference est utilisée. Sinon, la liste refcolumn doit faire référence aux colonnes d'une contrainte d'unicité ou de clé primaire non déferrable d'un index d'unicité non partiel. L'utilisateur doit avoir la permission REFERENCES sur la table référencée (soit toute la table, ou la colonne référencée spécifiquement). L'ajout d'une contrainte de type clé étrangère requiert un verrou SHARE ROW EXCLUSIVE sur la table référencée. Les contraintes de type clé étrangère ne peuvent pas être définies entre des tables temporaires et des tables permanentes.

Une valeur insérée dans les colonnes de la nouvelle table est comparée aux valeurs des colonnes de référence dans la table de référence à l'aide du type de concordance fourni. Il existe trois types de correspondance : MATCH FULL (NDT : correspondance totale), MATCH PARTIAL (NDT : correspondance partielle) et MATCH SIMPLE (NDT : correspondance simple), qui est aussi la valeur par défaut. MATCH FULL n'autorise une colonne d'une clé étrangère composite à être NULL que si l'ensemble des colonnes de la clé étrangère sont NULL. Si elles sont NULL, la ligne n'a pas besoin d'avoir une correspondance dans la table référencée. MATCH SIMPLE permet à n'importe quel colonne d'une clé étrangère d'être NULL ; si l'une d'entre elles est NULL, la ligne n'a pas besoin d'avoir une correspondance dans la table référencée. MATCH PARTIAL n'est pas encore implémentée. Bien sûr, les contraintes NOT NULL peuvent être appliquées sur la (ou les) colonne(s) référençantes pour empêcher ces cas de survenir.

Lorsque les données des colonnes référencées sont modifiées, des actions sont réalisées sur les données de la table référençant. La clause ON DELETE spécifie l'action à réaliser lorsqu'une ligne référencée de la table de référence est supprimée. De la même façon, la clause ON UPDATE spécifie l'action à réaliser lorsqu'une colonne référencée est mise à jour. Si la ligne est mise à jour sans que la valeur de la colonne référencée ne soit modifiée, aucune action n'est réalisée. Les actions référentielles autres que la vérification NO ACTION ne peuvent pas être différées même si la contrainte est déclarée retardable. Les actions suivantes sont possibles pour chaque clause :

Si les colonnes référencées sont modifiées fréquemment, il est conseillé d'ajouter un index sur les colonnes référençantes pour que les actions associées à la contrainte de clé étrangère soient plus performantes.

Ces clauses contrôlent la possibilité de différer la contrainte. Une contrainte qui n'est pas décalable dans le temps est vérifiée immédiatement après chaque commande. La vérification des contraintes décalables est repoussée à la fin de la transaction (à l'aide de la commande SET CONSTRAINTS). NOT DEFERRABLE est la valeur par défaut. Actuellement, seules les contraintes UNIQUE, PRIMARY KEY, EXCLUDE et REFERENCES (clé étrangère) acceptent cette clause. Les contraintes NOT NULL et CHECK ne sont pas diferrables. Notez que les contraintes différables ne peuvent pas être utilisées comme arbitres d'un conflit dans une commande INSERT qui inclut une clause ON CONFLICT DO UPDATE.

Si une contrainte est décalable dans le temps, cette clause précise le moment de la vérification. Si la contrainte est INITIALLY IMMEDIATE, elle est vérifiée après chaque instruction. Si la contrainte est INITIALLY DEFERRED, elle n'est vérifiée qu'à la fin de la transaction. Le moment de vérification de la contrainte peut être modifié avec la commande SET CONSTRAINTS.

Cette clause facultative permet de spécifier la méthode d'accès utilisée pour stocker le contenu de la nouvelle table. La méthode doit être une méthode d'accès de type TABLE. Voir Chapitre 60 pour plus d'informations. Si cette option n'est pas indiquée, la méthode d'accès par défaut est choisie pour la nouvelle table. Voir default_table_access_method pour plus d'informations.

Cette clause spécifie les paramètres de stockage optionnels pour une table ou un index ; voir Paramètres de stockage pour plus d'informations. Pour la rétro-compatibilité de la clause WITH d'une table, il est possible de spécifier OIDS=FALSE pour indiquer que les lignes de la nouvelle table ne doivent pas contenir d'OID (identifiants d'objets). OIDS=TRUE n'est plus supporté.

Il s'agit de la syntaxe rétro-compatible pour déclarer une table sans utiliser d'OID (identifiants d'objets), il n'est plus possible de créer une table avec l'option WITH OIDS.

Le comportement des tables temporaires à la fin d'un bloc de transactions est contrôlé à l'aide de la clause ON COMMIT. Les trois options sont :

nom_tablespace est le nom du tablespace dans lequel est créée la nouvelle table. S'il n'est pas spécifié, default_tablespace est consulté, sauf si la table est temporaire auquel cas temp_tablespaces est utilisé. Pour les tables partitionnées, comme la clause de stockage n'a pas de sens pour la table en elle-même, le tablespace indiqué écrase le default_tablespace comme tablespace par défaut à utiliser pour toute nouvelle partition à moins qu'un autre tablespace soit explicitement indiqué.

Les index associés à une contrainte UNIQUE, PRIMARY KEY, ou EXCLUDE sont créés dans le tablespace nommé nom_tablespace. S'il n'est pas précisé, default_tablespace est consulté, sauf si la table est temporaire auquel cas temp_tablespaces est utilisé.