| Documentation PostgreSQL 7.4.29 | ||||
|---|---|---|---|---|
| Pr�c�dent | Arri�re rapide | Avance rapide | Suivant | |
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE nom_table (
{ nom_colonne type_donn�es [ DEFAULT
default_expr ] [ contrainte_colonne [ ... ] ]
| contrainte_table
| LIKE table_parent [ { INCLUDING | EXCLUDING }
DEFAULTS ] } [, ... ]
)
[ INHERITS ( table_parent [, ... ] ) ]
[ WITH OIDS | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
o� contrainte_colonne
est :
[ CONSTRAINT nom_contrainte ]
{ NOT NULL | NULL | UNIQUE | PRIMARY KEY |
CHECK (expression) |
REFERENCES table_reference [ (
colonne_reference ) ] [ MATCH FULL
| MATCH PARTIAL | MATCH SIMPLE ]
[ ON DELETE action ] [ ON UPDATE action ] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
et contrainte_table est :
[ CONSTRAINT nom_contrainte ]
{ UNIQUE ( nom_colonne [, ... ] ) |
PRIMARY KEY ( nom_colonne [, ...
] ) |
CHECK ( expression ) |
FOREIGN KEY ( nom_colonne [, ...
] ) REFERENCES table_reference [ (
colonne_reference [, ... ] ) ]
[ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ] [ ON DELETE action ] [ ON UPDATE action ] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]CREATE TABLE cr�era une nouvelle table initialement vide dans la base de donn�es courante. La table sera la propri�t� de l'utilisateur qui a lan�� cette commande.
Si un nom de sch�ma est donn� (par exemple, CREATE TABLE monschema.matable ...), alors la table est cr��e dans le sch�ma sp�cifi�. Sinon, il est cr�� dans le sch�ma actuel. Les tables temporaires existent dans un sch�ma sp�cial, donc un nom de sch�ma pourrait ne pas �tre donn� lors de la cr�ation d'une table temporaire. Le nom de la table doit �tre distinct des noms des autres tables, s�quences, index ou vues dans le m�me sch�ma.
CREATE TABLE cr�e aussi automatiquement un type de donn�es qui repr�sente le type compos� correspondant � une ligne de la table. Du coup, les tables ne peuvent pas avoir le m�me nom que tout type de donn�es du m�me sch�ma.
Une table ne peut pas avoir plus de 1600 colonnes. (En pratique, la limite effective est plus basse � cause des contraintes de longueur de la ligne).
Les clauses de contrainte optionnelle sp�cifient les contraintes (ou tests) que les nouvelles lignes ou les lignes mises � jour doivent satisfaire pour qu'une op�ration d'insertion ou de mise � jour r�ussisse. Une contrainte est un objet SQL qui aide � d�finir l'ensemble de valeurs valides de plusieurs fa�ons.
Il existe deux fa�ons de d�finir des contraintes : les contraintes de table et celles des colonnes. Une contrainte de colonne est d�finie pour faire partie d'une d�finition de la colonne. Une d�finition de la contrainte des tables n'est pas li�e � une colonne particuli�re et elle comprend plus d'une colonne. Chaque contrainte de colonne peut aussi �tre �crite comme une contrainte de table ; une colonne de contrainte est seulement un outil de notation si la contrainte affecte seulement une colonne.
Si sp�cifi�, la table est cr��e comme une table 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 existantes avec le m�me nom ne sont pas visibles dans la session en cours alors que la table temporaire existe sauf si elles sont r�f�renc�es avec les noms qualifi�s du sch�ma. Tous les index cr��s sur une table temporaire sont aussi automatiquement temporaires.
Optionellement, GLOBAL ou LOCAL peuvent �tre �crit avant TEMPORARY ou TEMP. Ceci ne fait pas de diff�rence dans PostgreSQL, mais voir Compatibilit�.
Le nom (peut-�tre qualifi� par le nom du sch�ma) de la table � cr�er.
Le nom d'une colonne � cr�er dans la nouvelle table.
Le type de donn�es de la colonne. Ceci pourrait inclure des sp�cificateurs de tableaux.
La clause DEFAULT affecte une valeur par d�faut pour la colonne dont la d�finition appara�t � l'int�rieur. La valeur est toute expression libre de variable (les sous-requ�tes et r�f�rences crois�es aux autres colonnes dans la table en cours ne sont pas autoris�es). 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 sera utilis�e dans les op�rations d'insertion qui ne sp�cifient pas une valeur pour la colonne. S'il n'y a pas de valeur par d�faut pour une colonne, alors la valeur par d�faut est NULL.
La clause LIKE sp�cifie une table � partir de laquelle la nouvelle table h�rite automatiquement tous les noms de colonnes, leur types de donn�es et les contraintes non NULL.
Contrairement � INHERITS, la nouvelle table et la table h�rit�e sont compl�tement d�coupl�es apr�s la fin de la cr�ation. Les donn�es ins�r�es dans la nouvelle table ne sont pas refl�t�es dans la table parent.
Les expressions par d�faut pour les d�finitions des colonnes h�rit�es seront seulement incluses si INCLUDING DEFAULTS est sp�cifi�. Par d�faut, il faut exclure les expressions par d�faut.
La clause optionnelle INHERITS sp�cifie une liste des tables � partir desquelles la nouvelle table h�rite automatiquement de toutes les colonnes. Si le m�me nom de colonne existe dans plus d'une table parente, une erreur est rapport�e sauf si les types de donn�es des colonnes correspondent � chacune des tables parentes. S'il n'y a aucun conflit, alors les colonnes dupliqu�es sont assembl�es pour former une seule colonne dans la nouvelle table. Si la liste de noms de colonnes de la nouvelle table contient une colonne qui est aussi h�rit�e, le type de donn�es doit correspondre aux colonnes h�rit�es et les d�finitions de la colonne sont assembl�es en une seule. N�anmoins, les d�clarations des colonnes h�rit�es et nouvelles du m�me nom ont besoin de ne pas sp�cifier des contraintes identiques : toutes les contraintes fournies par toute d�claration sont assembl�es et sont toutes appliqu�es � la nouvelle table. Si la nouvelle table sp�cifie explicitement une valeur par d�faut pour la colonne, cette valeur surcharge toute valeur par d�faut des d�clarations h�rit�es pour la colonne.Sinon, tout parent sp�cifiant des valeurs par d�faut pour la colonne doit sp�cifier la m�me valeur par d�faut. Sinon une erreur sera rapport�e.
Cette clause optionnelle sp�cifie si les lignes de la nouvelle table devraient avoir des OID (identifiants d'objets) qui leur sont affect�s. Par d�faut, il y a des OID. (Si la nouvelle table h�rite d'autres tables poss�dant des OID, alors WITH OIDS est forc� m�me si la commande indique WITHOUT OIDS.)
Sp�cifier WITHOUT OIDS autorise l'utilisateur � supprimer la g�n�ration des OIDs pour les lignes d'une table. Ceci pourrait �tre int�ressant pour les grosses tables car il r�duit la consommation d'OID et, du coup, annule pour cette table le probl�me du retour � z�ro du compteur d'OID. Une fois que le compteur est revenu � z�ro, l'unicit� des OID ne peut plus �tre garantie, ce qui r�duit consid�rablement leur utilit�. Sp�cifier WITHOUT OIDS r�duit aussi l'espace requis pour stocker la table sur disque de quatre octets par ligne de la table, am�liorant ainsi leur performance.
Un nom optionnel pour une contrainte de colonne ou de table. S'il n'est pas sp�cifi�, le syst�me g�n�re un nom.
La colonne n'est pas autoris�e � contenir des valeurs NULL.
La colonne est autoris�e pour contenir des valeurs NULL. Ceci est la valeur par d�faut.
Cette clause est seulement disponible pour la compatibilit� avec les bases de donn�es SQL non standards. Son utilisation n'est pas encourag�e dans les nouvelles applications.
La contrainte UNIQUE sp�cifie qu'un groupe d'une ou plusieurs colonnes d'une table pourrait seulement contenir des valeurs uniques. Le comportement de la contrainte de table unique est le m�me que pour les contraintes de colonnes avec la capacit� suppl�mentaire de diviser les colonnes multiples.
Dans le but d'une contrainte unique, les valeurs NULL ne sont pas consid�r�es �gales.
Chaque contrainte de table unique doit nommer un ensemble de colonnes qui est diff�rent de l'ensemble des colonnes nomm�es par toute autre contrainte unique ou de cl� primaire d�finie pour la table. (Sinon, cela pourrait �tre juste la m�me contrainte donn�e deux fois.)
La contrainte de cl� primaire sp�cifie qu'une ou plusieurs colonnes d'une table pourraient contenir seulement des valeurs uniques, non NULL. Techniquement, PRIMARY KEY est simplement une combinaison de UNIQUE et NOT NULL, mais identifier un ensemble de colonnes comme cl� primaire fournit aussi des m�tadonn�es sur le concept du sch�ma, car une cl� primaire implique que d'autres tables pourraient se lier � cet ensemble de colonnes comme un unique identifiant pour les lignes.
Seule une cl� primaire peut �tre sp�cifi�e pour une table, s'il s'agit d'une contrainte de colonne ou de table.
La contrainte de cl� primaire devrait nommer un ensemble de colonnes qui est diff�rent des autres ensembles de colonnes nomm�s par une contrainte unique d�finie pour la m�me table.
La clause CHECK sp�cifie une expression produisant un r�sultat bool�en que les nouvelles lignes ou que les lignes mises � jour doivent satisfaire pour qu'une op�ration d'insertion ou de mise � jour r�ussisse. Une contrainte de v�rification sp�cifi�e comme une contrainte de colonne devrait seulement r�f�rencer la valeur de la colonne alors qu'une expression apparaissant dans une contrainte de table pourrait r�f�rencer plusieurs colonnes.
Actuellement, les expressions CHECK ne peuvent ni contenir des sous-requ�tes ni se r�f�rer � des variables autres que les colonnes de la ligne actuelle.
Ces clauses sp�cifient une contrainte de cl� �trang�re, ce qui sp�cifie qu'un groupe d'une ou plusieurs colonnes de la nouvelle table doit seulement contenir des valeurs correspondant aux valeurs dans le(s) colonne(s) r�f�renc�e(s) colonne_reference de la table r�f�renc�e table_reference. Si colonne_reference est omis, la cl� primaire de la table_reference est utilis�e. Les colonnes r�f�renc�es doivent �tre les colonnes d'une contrainte unique ou de cl� primaire dans la table r�f�renc�e.
Une valeur ins�r�e dans ces colonnes est compar�e aux valeurs de la table r�f�renc�e et des colonnes r�f�renc�es en utilisant le type correspondant donn�. Il existe trois types de correspondance : MATCH FULL, MATCH PARTIAL et MATCH SIMPLE, qui est aussi la valeur par d�faut. MATCH FULL n'autorisera pas une colonne d'une cl� �trang�re compos�e de plusieurs colonnes pour �tre NULL sauf si les colonnes de cl�s �trang�res sont nulles. MATCH SIMPLE autorise quelques colonnes de cl� �trang�re pour �tre NULL alors que les autres parties de la cl� �trang�re ne sont pas nulles. MATCH PARTIAL n'est pas encore impl�ment�.
En plus, lorsque les donn�es des colonnes r�f�renc�es sont modifi�es, certaines actions sont r�alis�es sur les donn�es dans les colonnes de cette table. La clause ON DELETE sp�cifie l'action � r�aliser lorsqu'une ligne r�f�renc�e de la table r�f�renc�e est en cours de suppression. De la m�me fa�on, la clause ON UPDATE sp�cifie l'action � r�aliser lorsqu'une colonne r�f�renc�e dans la table r�f�renc�e est en cours de mise � jour pour une nouvelle valeur. Si la ligne est mise � jour mais la colonne r�f�renc�e n'est pas r�ellement modifi�e, aucune action n'est r�alis�e. Il existe les actions possibles suivantes pour chaque clause :
Produit une erreur indiquant que la suppression ou la mise � jour cr�erait une violation de la contrainte de cl� �trang�re. Ceci est l'action par d�faut.
De m�me que NO ACTION sauf que cette action ne sera pas d�ferr�e m�me si le reste de la contrainte est d�ferrable et d�ferr�e.
Supprime toute ligne r�f�ren�ant la ligne supprim�e ou met � jour la valeur de la colonne r�f�renc�e avec la nouvelle valeur de la colonne r�f�renc�e, respectivement.
Initialise les valeurs de la colonne de r�f�rence � NULL.
Initialise les valeurs de la colonne de r�f�rence � leur valeur par d�faut.
Si la cl� primaire est mise � jour fr�quemment, il pourrait �tre conseill� d'ajouter un index vers la colonne de cl� �trang�re de fa�on � ce que les actions NO ACTION et CASCADE associ�es avec la colonne de cl� �trang�re puissent �tre r�alis�es avec efficacit�.
Ceci contr�le si la contrainte peut �tre d�ferr�e. Une contrainte qui n'est pas d�ferrable sera v�rifi�e imm�diatement apr�s chaque commande. La v�rification des contraintes qui sont d�ferrables pourraient attendre la fin de la transaction (en utilisant la commande SET CONSTRAINTS). NOT DEFERRABLE est la valeur par d�faut. Seulement des contraintes de cl� �trang�re acceptent r�ellement cette clause. Tous les autres types de contraintes ne sont pas d�ferrables.
Si une contrainte est d�ferrable, cette clause sp�cifie le temps par d�faut pour v�rifier la contrainte. Si la contrainte est INITIALLY IMMEDIATE, elle est v�rifi�e apr�s chaque instruction. Si la contrainte est INITIALLY DEFERRED, elle est v�rifi�e seulement � la fin de la transaction. Le moment de v�rification de la contrainte peut �tre modifi� avec la commande SET CONSTRAINTS.
Le comportement des tables temporaires � la fin d'un bloc de transaction peut se contr�ler en utilisant ON COMMIT. Les trois options sont
Aucune action n'est prise � la fin des transactions. Ceci est le comportement par d�faut.
Toutes les lignes dans la table temporaire seront d�truites � la fin de chaque bloc de transaction. En fait, un TRUNCATE automatique est r�alis� � chaque validation.
La table temporaire sera supprim�e � la fin du bloc de transaction.
� chaque fois qu'une application utilise les OID pour identifier des lignes sp�cifiques d'une table, il est recommand� de cr�er une contrainte unique sur la colonne oid de cette table pour s'assurer que les OID de la table identifieront les lignes r�ellement de fa�on unique m�me apr�s une remise � z�ro du compteur. �vitez d'assumer que les OID sont uniques pour les diff�rentes tables ; si vous avez besoin d'un identifiant unique sur la base de donn�es, utilisez une combinaison de tableoid et de l'OID de la ligne dans ce but. (Il est probable que les versions futures de PostgreSQL utiliseront un compteur OID s�par� pour chaque table, de fa�on � ce qu'il soit n�cessaire, et non pas optionnel, d'inclure tableoid pour avoir un identifiant unique pour la base de donn�es.)
Astuce�: L'utilisation de WITHOUT OIDS n'est pas recommand�e pour les tables sans cl� primaire car, sans soit un OID soit une cl� de donn�es unique, il est difficile d'identifier des lignes sp�cifiques.
PostgreSQL cr�e automatiquement un index pour chaque contrainte unique et pour chaque contrainte de cl� �trang�re pour renforcer l'unicit�. Du coup, il n'est pas n�cessaire de cr�er un index sp�cifique pour les colonnes de cl�s primaires. (Voir CREATE INDEX pour plus d'informations.)
Les contraintes uniques et les cl�s primaires ne sont pas h�rit�es dans l'impl�mentation actuelle. Ceci rend la combinaison de l'h�ritage et des contraintes uniques assez disfonctionnelle.
Cr�ez une table films et une table distributeurs :
CREATE TABLE films (
code char(5) CONSTRAINT premierecle PRIMARY KEY,
titre varchar(40) NOT NULL,
did integer NOT NULL,
date_prod date,
genre varchar(10),
duree interval hour to minute
);
CREATE TABLE distributeurs (
did integer PRIMARY KEY DEFAULT nextval('serial'),
nom varchar(40) NOT NULL CHECK (nom <> '')
);
Cr�e une table avec un tableau � deux dimensions :
CREATE TABLE array (
vecteur int[][]
);
D�finir une contrainte unique de table pour la table films. Les contraintes uniques de table peuvent �tre d�finies sur une ou plusieurs colonnes de la table.
CREATE TABLE films (
code char(5),
titre varchar(40),
did integer,
date_prod date,
genre varchar(10),
duree interval hour to minute,
CONSTRAINT production UNIQUE(date_prod)
);
D�finir une contrainte de colonne de v�rification :
CREATE TABLE distributeurs (
did integer CHECK (did > 100),
nom varchar(40)
);
D�finir une contrainte de table de v�rification :
CREATE TABLE distributeurs (
did integer,
nom varchar(40)
CONSTRAINT con1 CHECK (did > 100 AND nom <> '')
);
D�finir une contrainte de cl� primaire sur la table films. Les contraintes de cl� primaire peuvent �tre d�finies sur une ou plusieurs colonnes de la table.
CREATE TABLE films (
code char(5),
titre varchar(40),
did integer,
date_prod date,
genre varchar(10),
duree interval hour to minute,
CONSTRAINT code_titre PRIMARY KEY(code,titre)
);
D�finir une contrainte de cl� primaire pour la table distributeurs. Les deux exemples suivants sont �quivalents, le premier utilisant la syntaxe de contrainte de la table, le second la notation de contrainte de la colonne.
CREATE TABLE distributeurs (
did integer,
nom varchar(40),
PRIMARY KEY(did)
);
CREATE TABLE distributeurs (
did integer PRIMARY KEY,
nom varchar(40)
);
Ceci affecte une valeur par d�faut pour la colonne nom, arrange la valeur par d�faut de la colonne did pour �tre g�n�r�e en s�lectionnant la prochaine valeur d'un objet s�quence et fait que la valeur par d�faut de modtime soit le moment o� la ligne est ins�r�e.
CREATE TABLE distributeurs (
name varchar(40) DEFAULT 'Luso Films',
did integer DEFAULT nextval('distributeurs_serial'),
modtime timestamp DEFAULT current_timestamp
);
D�finir deux contraintes de colonnes NOT NULL sur la table
distributeurs, dont une se voit donner explicitement
un nom :
CREATE TABLE distributeurs (
did integer CONSTRAINT no_null NOT NULL,
nom varchar(40) NOT NULL
);
D�finit une contrainte unique pour la colonne nom :
CREATE TABLE distributeurs (
did integer,
nom varchar(40) UNIQUE
);Ce qui se trouve ci-dessus est �quivalent � ce qui suit, sp�cifi� comme une contrainte de table :
CREATE TABLE distributeurs (
did integer,
nom varchar(40),
UNIQUE(nom)
);
La commande CREATE TABLE se conforme � SQL92 et � un sous-ensemble de SQL99, avec les exceptions indiqu�es ci-dessous.
Bien que la syntaxe de CREATE TEMPORARY TABLE ressemble � celle du SQL standard, l'effet n'est pas le m�me. Dans le standard, les tables temporaires sont d�finies seulement une fois et existent automatiquement (en commen�ant avec un contenu vide) dans chaque session qui en a besoin. � la place, PostgreSQL requiert que chaque session lance sa propre commande CREATE TEMPORARY TABLE pour chaque table temporaire � utiliser. Ceci permet � diff�rentes sessions d'utiliser le m�me nom de table temporaire dans des buts diff�rents alors que l'approche du standard contraint toutes les instances d'un nom de table temporaire donn� pour avoir la m�me structure de table.
La d�finition du standard pour le comportement des tables temporaires est largement ignor�e. Le comportement de PostgreSQL sur ce point est similaire � celui de nombreuses autres bases de donn�es SQL.
La distinction du standard entre tables temporaires globales et locales n'est pas dans PostgreSQL car cette distinction d�pend du concept de modules, que PostgreSQL ne poss�de pas. Pour le bien de la compatibilit�, PostgreSQL acceptera les mots cl�s GLOBAL et LOCAL dans la d�claration d'une table temporaire mais cela n'aura aucun effet.
La clause ON COMMIT pour les tables temporaires ressemble aussi au standard SQL mais a quelques diff�rences. Si la clause ON COMMIT est omise, SQL sp�cifie que le comportement par d�faut est ON COMMIT DELETE ROWS. N�anmoins, le comportement par d�faut dans PostgreSQL est ON COMMIT PRESERVE ROWS. L'option ON COMMIT DROP n'existe pas en SQL.
Le standard SQL dit que les contraintes de v�rification CHECK de colonne pourraient seulement r�f�rencer la colonne � laquelle elles s'appliquent ; seulement les contraintes de tables CHECK pourraient se r�f�rencer � de nombreuses colonnes. PostgreSQL ne force pas cette restriction ; il traite de la m�me fa�on les contraintes de v�rifications des colonnes et des tables.
La <<�contrainte�>> NULL (r�ellement une non-contrainte) est une extension PostgreSQL au standard SQL qui est inclus pour des raisons de compatibilit� avec quelques autres syst�mes de bases de donn�es (et pour la sym�trie avec la contrainte NOT NULL). Comme ceci est la valeur par d�faut de cette colonnes, sa pr�sence est un simple bruit.
Plusieurs h�ritages via la clause INHERITS est une extension du langage PostgreSQL. SQL99 (et non pas SQL92) d�finit un h�ritage simple en utilisant une syntaxe et des s�mantiques diff�rentes. L'h�ritage style SQL99 n'est pas encore support� par PostgreSQL.
PostgreSQL autorise la cr�ation de tables sans colonnes (par exemple, CREATE TABLE foo();). Ceci est une extension du standard SQL, qui ne le permet pas. Les tables sans colonnes ne sont pas tr�s utiles mais les d�sactiver pourrait apporter quelques cas bizarres sp�ciaux pour ALTER TABLE DROP COLUMN, donc il semble plus propre d'ignorer la restriction de cette sp�cification.
| Pr�c�dent | Sommaire | Suivant |
| CREATE SEQUENCE | Niveau sup�rieur | CREATE TABLE AS |