| Documentation PostgreSQL 8.0.25 | ||||
|---|---|---|---|---|
| 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 } ]
[ TABLESPACE tablespace ]
o� contrainte_colonne
est :
[ CONSTRAINT nom_contrainte ]
{ NOT NULL | NULL | UNIQUE [ USING INDEX TABLESPACE espacelogique ] |
PRIMARY KEY [ USING INDEX TABLESPACE espacelogique ] |
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 [, ... ] ) [ USING INDEX TABLESPACE espacelogique ] |
PRIMARY KEY ( nom_colonne [, ...
] ) [ USING INDEX TABLESPACE espacelogique ] |
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.
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 � utiliser lorsque 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. Pour plus d'informations sur les types de donn�es support�s par PostgreSQL, r�f�rez-vous � Chapitre 8.
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 optionnelle INHERITS sp�cifie une liste des tables � partir desquelles la nouvelle table h�rite automatiquement de toutes les colonnes.
L'utilisation d'INHERITS cr�e une relation persistante entre la nouvelle table enfant et sa table parent. Les modifications du sch�ma au(x) parent(s) se propagent normalement aussi aux enfants et, par d�faut, les donn�es de la table enfant sont inclus dans les parcours de(s) parent(s).
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 un nom de 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.
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 h�rit�e sont compl�tement d�coupl�es apr�s la fin de la cr�ation. Les modifications sur la table originale ne sont pas appliqu�es � la nouvelle table et il n'est pas possible d'inclure les donn�es de la nouvelle table dans des parcours de l'ancienne table.
Les expressions par d�faut pour les d�finitions des colonnes h�rit�es seront seulement copi�es si INCLUDING DEFAULTS est sp�cifi�. Le comportement par d�faut est d'exclure les expressions par d�faut, ce qui a pour r�sultat d'avoir des valeurs par d�faut NULL pour toutes les colonnes de la nouvelle table.
Cette clause optionnelle sp�cifie si les lignes de la nouvelle table devraient avoir des OID (identifiants d'objets) qui leur sont affect�s. Si ni WITH OIDS ni WITHOUT OIDS ne sont sp�cifi�s, la valeur par d�faut d�pend du param�tre de configuration default_with_oids. (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.)
Si WITHOUT OIDS est sp�cifi� ou implicite, la nouvelle table ne stocke pas les OID aucun OID ne sera affect� pour une ligne ins�r�e dans cette table. Ceci est g�n�ralement consid�r� comme 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�. De plus, exclure les OID d'une table r�duit aussi l'espace requis pour stocker la table sur disque de quatre octets par ligne de la table (sur la plupart des machines), am�liorant ainsi leur performance.
Pour supprimer les OID d'une table apr�s qu'elle ait �t� cr��e, utilisez ALTER TABLE.
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 fournie 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. Les expressions �valuant � TRUE ou UNKNOWN r�ussissent. Si une ligne d'une op�ration d'insertion ou de mise � jour produit un r�sultat FALSE, une exception est lev�e et l'insertion ou la mise � jour ne modifie pas la base de donn�es. 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 requiert 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) de quelques lignes de la table r�f�renc�e. 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 les colonnes r�f�renc�es 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. Les actions r�f�renc�es autres que la v�rification de contrainte NO ACTION ne peuvent pas �tre d�ferr�es m�me si la contrainte est d�clar�e comme d�ferrable. 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. Si la contrainte est d�ferr�e, cette erreur sera produite au moment de la v�rification de la contrainte s'il existe toujours des lignes de r�f�rence. Ceci est l'action par d�faut.
Produit une erreur indiquant que la suppression ou mise � jour cr�era une violation de la contrainte de cl� �trang�re. Ceci est identique � NO ACTION sauf que la v�rification n'est pas d�ferrable.
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 la colonne de r�f�rence � NULL.
Initialise la colonne de r�f�rence � sa valeur par d�faut.
Si les colonnes r�f�renc�es sont modifi�es fr�quemment, il pourrait �tre conseill� d'ajouter un index vers la colonne de cl� �trang�re de fa�on � ce que les actions r�f�rentielles 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.
Le tablespace est le nom du tablespace dans lequel est cr��e la nouvelle table. Si elle n'est pas sp�cifi�e, default_tablespace est utilis�e ou le tablespace par d�faut de la base de donn�es si default_tablespace est une cha�ne vide.
Cette clause permet la s�lection du tablespace dans lequel les index associ�s � une contrainte UNIQUE ou PRIMARY KEY seront cr��s. Si elle n'est pas sp�cifi�e, default_tablespace est utilis�e ou le tablespace par d�faut de la base de donn�es si default_tablespace est une cha�ne vide.
Utiliser les OID dans les nouvelles applications n'est pas recommand� : si possible, utilisez de pr�f�rence un SERIAL ou un autre g�n�rateur de s�quence comme cl� primaire de la table. N�anmoins, si votre 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.
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�cifiquement 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.
Une table ne peut pas avoir plus de 1600 colonnes (en pratique, la limite r�elle est plus basse � cause de contraintes sur la longueur des lignes).
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_int (
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 syntaxe 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)
);
Cr�er une table cinemas dans le tablespace diskvol1 :
CREATE TABLE cinemas (
id serial,
nom text,
emplacement text
) TABLESPACE diskvol1;
La commande CREATE TABLE se conforme � SQL-92 et � un sous-ensemble de SQL:1999, 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. SQL:1999 (et non pas SQL-92) d�finit un h�ritage simple en utilisant une syntaxe et des s�mantiques diff�rentes. L'h�ritage style SQL:1999 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 |