ADD COLUMN
Ce formulaire ajoute une nouvelle colonne à la table, en utilisant la même syntaxe que CREATE TABLE.
DROP COLUMN
Ce formulaire supprime une colonne d’une table. Les index et les contraintes de table impliquant la colonne seront également automatiquement supprimés. Vous devrez dire CASCADE si quelque chose en dehors de la table dépend de la colonne, par exemple, des références de clés étrangères ou des vues. Si IF EXISTS est spécifié et que la colonne n’existe pas, aucune erreur n’est émise. Dans ce cas, un avis est émis à la place.
SET DATA TYPE
Ce formulaire modifie le type d’une colonne d’une table. Les index et les contraintes de table simples impliquant la colonne seront automatiquement convertis pour utiliser le nouveau type de colonne en reparsant l’expression fournie à l’origine. La clause facultative COLLATE spécifie une collation pour la nouvelle colonne ; si elle est omise, la collation est celle par défaut pour le nouveau type de colonne. La clause facultative USING spécifie comment calculer la nouvelle valeur de la colonne à partir de l’ancienne ; si elle est omise, la conversion par défaut est la même que celle d’une affectation de l’ancien type de données au nouveau. Une clause USING doit être fournie s’il n’y a pas de cast implicite ou d’affectation de l’ancien au nouveau type.
SET/DROP DEFAULT
Ces formulaires définissent ou suppriment la valeur par défaut d’une colonne. Les valeurs par défaut ne s’appliquent qu’aux commandes INSERT ultérieures ; elles n’entraînent pas de modification des lignes déjà présentes dans la table. Les valeurs par défaut peuvent également être créées pour les vues, auquel cas elles sont insérées dans les instructions INSERT sur la vue avant que la règle ON INSERT de la vue ne soit appliquée.
SET/DROP NOT NULL
Ces formulaires changent si une colonne est marquée pour autoriser les valeurs nulles ou pour rejeter les valeurs nulles. Vous ne pouvez utiliser SET NOT NULL que lorsque la colonne ne contient aucune valeur nulle.
SET STATISTICS
Ce formulaire définit la cible de collecte de statistiques par colonne pour les opérations ANALYZE ultérieures. La cible peut être définie dans la plage de 0 à 10000 ; alternativement, définissez-la à -1 pour revenir à l’utilisation de la cible de statistiques par défaut du système (default_statistics_target). Pour plus d’informations sur l’utilisation des statistiques par le planificateur de requêtes PostgreSQL, reportez-vous à la section 14.2.
SET ( attribute_option = value )
RESET ( attribute_option )
Cette forme définit ou réinitialise les options par attribut. Actuellement, les seules options par attribut définies sont n_distinct et n_distinct_inherited, qui remplacent les estimations du nombre de valeurs distinctes effectuées par les opérations ANALYZE ultérieures. n_distinct affecte les statistiques de la table elle-même, tandis que n_distinct_inherited affecte les statistiques recueillies pour la table plus ses enfants d’héritage. Lorsqu’il est défini à une valeur positive, ANALYZE va supposer que la colonne contient exactement le nombre spécifié de valeurs distinctes non nulles. Lorsqu’il est défini à une valeur négative, qui doit être supérieure ou égale à -1, ANALYZE suppose que le nombre de valeurs distinctes non nulles dans la colonne est linéaire par rapport à la taille de la table ; le nombre exact doit être calculé en multipliant la taille estimée de la table par la valeur absolue du nombre donné. Par exemple, une valeur de -1 implique que toutes les valeurs de la colonne sont distinctes, tandis qu’une valeur de -0,5 implique que chaque valeur apparaît deux fois en moyenne. Cela peut être utile lorsque la taille de la table change au fil du temps, puisque la multiplication par le nombre de lignes de la table n’est pas effectuée avant la planification de la requête. Spécifiez une valeur de 0 pour revenir à l’estimation normale du nombre de valeurs distinctes. Pour plus d’informations sur l’utilisation des statistiques par le planificateur de requêtes PostgreSQL, reportez-vous à la section 14.2.
SET STORAGE
Ce formulaire définit le mode de stockage d’une colonne. Cela contrôle si cette colonne est maintenue en ligne ou dans une table TOAST secondaire, et si les données doivent être compressées ou non. PLAIN doit être utilisé pour les valeurs de longueur fixe comme les entiers et est en ligne, non compressé. MAIN est pour les données en ligne, compressibles. EXTERNAL est pour les données externes, non compressées, et EXTENDED est pour les données externes, compressées. EXTENDED est la valeur par défaut pour la plupart des types de données qui prennent en charge le stockage non-PLAIN. L’utilisation de EXTERNAL accélérera les opérations de sous-chaînes sur les très grandes valeurs de texte et d’octets, au prix d’un espace de stockage accru. Notez que SET STORAGE ne change rien en soi dans la table, il définit simplement la stratégie à suivre lors des futures mises à jour de la table. Voir la section 55.2 pour plus d’informations.
ADD table_constraint
Ce formulaire ajoute une nouvelle contrainte à une table en utilisant la même syntaxe que CREATE TABLE, plus l’option NOT VALID, qui n’est actuellement autorisée que pour les contraintes de clé étrangère. Si la contrainte est marquée NOT VALID, la vérification initiale, potentiellement longue, pour vérifier que toutes les lignes de la table satisfont à la contrainte, est ignorée. La contrainte sera toujours appliquée aux insertions ou mises à jour ultérieures (c’est-à-dire qu’elles échoueront à moins qu’il n’y ait une ligne correspondante dans la table référencée). Mais la base de données ne supposera pas que la contrainte tient pour toutes les lignes de la table, jusqu’à ce qu’elle soit validée en utilisant l’option VALIDATE CONSTRAINT.
ADD table_constraint_using_index
Ce formulaire ajoute une nouvelle contrainte PRIMARY KEY ou UNIQUE à une table basée sur un index unique existant. Toutes les colonnes de l’index seront incluses dans la contrainte.
L’index ne peut pas avoir de colonnes d’expression ni être un index partiel. De plus, il doit être un index b-tree avec un ordre de tri par défaut. Ces restrictions garantissent que l’index est équivalent à celui qui serait construit par une commande ADD PRIMARY KEY ou ADD UNIQUE ordinaire.
Si PRIMARY KEY est spécifié, et que les colonnes de l’index ne sont pas déjà marquées NOT NULL, alors cette commande tentera de faire ALTER COLUMN SET NOT NULL contre chacune de ces colonnes. Cela nécessite un balayage complet de la table pour vérifier que la ou les colonnes ne contiennent pas de valeurs nulles. Dans tous les autres cas, c’est une opération rapide.
Si un nom de contrainte est fourni, alors l’index sera renommé pour correspondre au nom de la contrainte. Sinon, la contrainte sera nommée de la même manière que l’index.
Après l’exécution de cette commande, l’index est « possédé » par la contrainte, de la même manière que si l’index avait été construit par une commande ADD PRIMARY KEY ou ADD UNIQUE régulière. En particulier, l’abandon de la contrainte fera disparaître l’index aussi.
Note : L’ajout d’une contrainte en utilisant un index existant peut être utile dans les situations où une nouvelle contrainte doit être ajoutée sans bloquer les mises à jour de la table pendant une longue période. Pour ce faire, créez l’index en utilisant CREATE INDEX CONCURRENTLY, puis installez-le en tant que contrainte officielle en utilisant cette syntaxe. Voir l’exemple ci-dessous.
VALIDER CONSTRAINT
Ce formulaire valide une contrainte de clé étrangère qui a été précédemment créée comme NON VALIDE, en balayant la table pour s’assurer qu’il n’y a pas de lignes non appariées. Rien ne se passe si la contrainte est déjà marquée comme valide.
La validation peut être un long processus sur des tables plus grandes et nécessite actuellement un verrou ACCESS EXCLUSIVE. La valeur de la séparation de la validation de la création initiale est que vous pouvez reporter la validation à des périodes moins occupées, ou peut être utilisée pour donner du temps supplémentaire pour corriger les erreurs préexistantes tout en empêchant de nouvelles erreurs.
DROP CONSTRAINT
Ce formulaire fait tomber la contrainte spécifiée sur une table. Si IF EXISTS est spécifié et que la contrainte n’existe pas, aucune erreur n’est lancée. Dans ce cas, un avis est émis à la place.
DISABLE/ENABLE TRIGGER
Ces formulaires configurent le déclenchement du ou des déclencheurs appartenant à la table. Un déclencheur désactivé est toujours connu du système, mais n’est pas exécuté lorsque son événement déclencheur se produit. Pour un déclencheur différé, l’état d’activation est vérifié lorsque l’événement se produit, et non lorsque la fonction de déclenchement est effectivement exécutée. On peut désactiver ou activer un seul déclencheur spécifié par son nom, ou tous les déclencheurs de la table, ou seulement les déclencheurs de l’utilisateur (cette option exclut les déclencheurs de contraintes générés en interne, comme ceux qui sont utilisés pour mettre en œuvre les contraintes de clé étrangère ou les contraintes d’unicité et d’exclusion différées). La désactivation ou l’activation des déclencheurs de contraintes générés en interne nécessite des privilèges de super-utilisateur ; elle doit être effectuée avec prudence car, bien entendu, l’intégrité de la contrainte ne peut être garantie si les déclencheurs ne sont pas exécutés. Le mécanisme de déclenchement des déclencheurs est également affecté par la variable de configuration session_replication_role. Les déclencheurs simplement activés se déclencheront lorsque le rôle de réplication est « origin » (par défaut) ou « local ». Les déclencheurs configurés comme ENABLE REPLICA se déclencheront uniquement si la session est en mode « réplica », et les déclencheurs configurés comme ENABLE ALWAYS se déclencheront quel que soit le mode de réplication actuel.
DISABLE/ENABLE RULE
Ces formulaires configurent le déclenchement des règles de réécriture appartenant à la table. Une règle désactivée est toujours connue du système, mais n’est pas appliquée pendant la réécriture de la requête. La sémantique est la même que pour les triggers désactivés/activés. Cette configuration est ignorée pour les règles ON SELECT, qui sont toujours appliquées afin de maintenir le fonctionnement des vues même si la session actuelle est dans un rôle de réplication non par défaut.
CLUSTER
Ce formulaire sélectionne l’index par défaut pour les futures opérations CLUSTER. Il ne re-classe pas réellement la table.
SET WITHOUT CLUSTER
Ce formulaire supprime la spécification d’index CLUSTER la plus récemment utilisée de la table. Cela affecte les futures opérations de cluster qui ne spécifient pas d’index.
SET WITH OIDS
Ce formulaire ajoute une colonne système oid à la table (voir Section 5.4). Il ne fait rien si la table a déjà des OID.
Notez que ce n’est pas équivalent à ADD COLUMN oid oid ; cela ajouterait une colonne normale qui se trouve être nommée oid, pas une colonne système.
SET WITHOUT OIDS
Ce formulaire supprime la colonne système oid de la table. C’est exactement équivalent à DROP COLUMN oid RESTRICT, sauf qu’il ne se plaindra pas s’il n’y a pas déjà de colonne oid.
SET ( storage_parameter = value )
Ce formulaire modifie un ou plusieurs paramètres de stockage pour la table. Voir Paramètres de stockage pour plus de détails sur les paramètres disponibles. Notez que le contenu de la table ne sera pas modifié immédiatement par cette commande ; selon le paramètre, vous devrez peut-être réécrire la table pour obtenir les effets désirés. Cela peut être fait avec VACUUM FULL, CLUSTER ou l’une des formes de ALTER TABLE qui force une réécriture de la table.
Note : Alors que CREATE TABLE permet de spécifier OIDS dans la syntaxe WITH (storage_parameter), ALTER TABLE ne traite pas OIDS comme un paramètre de stockage. Utilisez plutôt les formulaires SET WITH OIDS et SET WITHOUT OIDS pour modifier le statut des OID.
RESET ( storage_parameter )
Ce formulaire réinitialise un ou plusieurs paramètres de stockage à leurs valeurs par défaut. Comme avec SET, une réécriture de la table pourrait être nécessaire pour mettre à jour entièrement la table.
INHERIT parent_table
Ce formulaire ajoute la table cible comme nouvel enfant de la table parent spécifiée. Par la suite, les requêtes contre le parent incluront les enregistrements de la table cible. Pour être ajoutée en tant qu’enfant, la table cible doit déjà contenir toutes les mêmes colonnes que le parent (elle peut aussi avoir des colonnes supplémentaires). Les colonnes doivent avoir des types de données correspondants, et si elles ont des contraintes NOT NULL dans le parent, alors elles doivent aussi avoir des contraintes NOT NULL dans l’enfant.
Il doit aussi y avoir des contraintes de table enfant correspondantes pour toutes les contraintes CHECK du parent. Actuellement, les contraintes UNIQUE, PRIMARY KEY et FOREIGN KEY ne sont pas prises en compte, mais cela pourrait changer à l’avenir.
NO INHERIT parent_table
Ce formulaire supprime la table cible de la liste des enfants de la table parent spécifiée. Les requêtes contre la table parent n’incluront plus les enregistrements tirés de la table cible.
OF nom_type
Ce formulaire lie la table à un type composite comme si CREATE TABLE OF l’avait formé. La liste des noms et des types de colonnes de la table doit correspondre précisément à celle du type composite ; la présence d’une colonne du système oid est autorisée pour différer. La table ne doit pas hériter d’une autre table. Ces restrictions garantissent que CREATE TABLE OF permettrait une définition de table équivalente.
NOT OF
Ce formulaire dissocie une table typée de son type.
OWNER
Ce formulaire change le propriétaire de la table, de la séquence ou de la vue pour l’utilisateur spécifié.
SET TABLESPACE
Ce formulaire change le tablespace de la table pour le tablespace spécifié et déplace le ou les fichiers de données associés à la table vers le nouveau tablespace. Les index de la table, s’il y en a, ne sont pas déplacés ; mais ils peuvent être déplacés séparément avec des commandes SET TABLESPACE supplémentaires. Voir également CREATE TABLESPACE.
RENAME
Les formulaires RENAME modifient le nom d’une table (ou d’un index, d’une séquence ou d’une vue) ou le nom d’une colonne individuelle dans une table. Il n’y a aucun effet sur les données stockées.
SET SCHEMA
Ce formulaire déplace la table dans un autre schéma. Les index, contraintes et séquences associés appartenant aux colonnes de la table sont également déplacés.