CREATE DATABASE — Créer une nouvelle base de données
CREATE DATABASEnom[ WITH ] [ OWNER [=]nom_utilisateur] [ TEMPLATE [=]modèle] [ ENCODING [=]codage] [ STRATEGY [=]stratégie] [ LOCALE [=]locale] [ LC_COLLATE [=]lc_collate] [ LC_CTYPE [=]lc_ctype] [ BUILTIN_LOCALE [=]locale_native] [ ICU_LOCALE [=]locale_icu] [ ICU_RULES [=]regles_icu] [ LOCALE_PROVIDER [=]fournisseur_locale] [ COLLATION_VERSION =version_collation] [ TABLESPACE [=]tablespace] [ ALLOW_CONNECTIONS [=]connexion_autorisee] [ CONNECTION LIMIT [=]limite_connexion] [ IS_TEMPLATE [=]est_template] ] [ OID [=]oid]
CREATE DATABASE crée une nouvelle
base de données.
Pour créer une base de données, il faut être superutilisateur
ou avoir le droit spécial CREATEDB.
Voir à ce sujet CREATE USER.
Par défaut, la nouvelle base de données est créée en clonant la base
système standard template1. Un modèle différent peut
être utilisé en écrivant TEMPLATE . En particulier, la clause
nomTEMPLATE template0 permet de créer une base de données
vierge (une base où aucun objet défini par un utilisateur n'existe et où
les objets système n'ont pas été modifiés) qui ne contient que les objets
standards pré-définis dans la version de
PostgreSQL utilisée. C'est utile pour ne pas
copier les objets locaux ajoutés à template1.
nom #Le nom de la base de données à créer.
nom_utilisateur #
Le nom de l'utilisateur propriétaire de la nouvelle base de données ou
DEFAULT pour l'option par défaut (c'est-à-dire le
nom de l'utilisateur qui exécute la commande). Pour créer une base de
données dont le propriétaire est un autre rôle, vous devez être capable
d'exécuter SET ROLE vers ce rôle.
modèle #
Le nom du modèle squelette de la nouvelle base de données ou
DEFAULT pour le modèle par défaut
(template1).
encodage #
Le jeu de caractères de la nouvelle base de données.
Peut-être une chaîne (par exemple 'SQL_ASCII'), un
nombre de jeu de caractères de type entier ou DEFAULT
pour le jeu de caractères par défaut (en fait, celui de la base
modèle).
Les jeux de caractères supportés par le serveur
PostgreSQL sont décrits dans
Section 23.3.1.
Voir ci-dessous pour des restrictions supplémentaires.
stratégie #
Stratégie à utiliser pour la création d'un nouvelle base de données. Si
la stratégie WAL_LOG est utilisée, la base sera copiée
bloc par bloc et chaque bloc sera écrit séparément dans les journaux de
transactions. C'est la stratégie la plus efficace dans le cas où la base
est petit et, de ce fait, c'est la stratégie par défaut. La stratégie
plus ancienne, FILE_COPY, est aussi disponible. Cette
stratégie écrit un petit enregistrement dans le journal pour chaque
tablespace utilisé par la base de données cible. Chaque enregistrement
représente la copie d'un répertoire entier vers un nouvel emplacement au
niveau du système de fichiers. Bien que cela réduise fortement le volume
des journaux de transactions, tout spécialement si la base modèle est
volumineuse, cela force aussi le système à exécuter un checkpoint avant et
après la création de la nouvelle base. Dans certaines situations, ceci
pourrait avoir un impact négatif visible sur les performances globales du
système.
locale #
Configure la tri de collation et la classification des caractères par
défaut dans la nouvelle base de données. La collation affecte l'ordre
de tri appliqué aux chaînes, par exemple dans les requêtes avec
ORDER BY, ainsi que l'ordre utilisé dans les index
pour les colonnes de texte. La classification des caractères affecte
la catégorisation des caractères, par exemple minuscule, majuscule et
chiffre. De plus, configure les aspects associés de l'environnement du
système d'exploitation,
LC_COLLATE et LC_CTYPE. La
valeur par défaut correspond au paramétrage de la base de données
modèle. Voir Section 23.2.2.3.1 et Section 23.2.2.3.2 pour les détails.
Peut être surchargé en configurant individuellement lc_collate, lc_ctype, builtin_locale ou locale_icu.
Si fournisseur_locale vaut
builtin, alors locale ou
builtin_locale doit être indiqué et
configuré soit à C soit à C.UTF-8.
Les autres paramètres de locales, à savoir lc_messages, lc_monetary, lc_numeric et lc_time, ne sont
pas fixés par base de données et ne sont donc pas configurés par cette
commande. Si vous voulez le faire pour une base spécifique, vous pouvez
utiliser ALTER DATABASE ... SET.
lc_collate #
Configure LC_COLLATE dans l'environnement du système
d'exploitation du serveur. La valeur par défaut est la configuration de
locale si indiqué. Sinon, la configuration
est identique à la base modèle. Voir ci-dessous pour les restrictions
supplémentaires..
Si fournisseur_locale vaut
libc, alors configure l'ordre de collation par défaut
à utiliser dans la nouvelle base de données, surchargeant ainsi la
configuration de locale.
lc_ctype #
Configure LC_CTYPE dans l'environnement du système
d'exploitation du serveur. La valeur par défaut est la configuration de
locale si indiqué. Sinon, la configuration
est identique à la base modèle. Voir ci-dessous pour les restrictions
supplémentaires.
Si fournisseur_locale vaut
libc, alors configure la classification des caractères
par défaut à utiliser dans la nouvelle base de données, surchargeant ainsi
la configuration de locale.
builtin_locale #
Indique la locale du fournisseur natif pour la classification d'ordre et
de caractères par défaut de la base de données, surchargeant la
configuration locale. Le fournisseur de locale
doit être builtin. La valeur par défaut correspond à
la valeur de locale si indiqué ;
sinon, c'est la même configuration que celle de la base modèle.
Les locales disponibles pour le fournisseur builtin
sont C et C.UTF-8.
locale_icu #
Indique la locale ICU (voir Section 23.2.2.3.2) pour le tri de collation
et la classification des caractères par défaut, surchargeant la
configuration de locale. le fournisseur de locale
doit être ICU. La valeur par défaut correspond à la configuration de
locale si indiquée ; sinon
même configuration que la base de données modèle.
règles_icu #Indique les règles de collation supplémentaires pour personnaliser le comportement de la collation par défaut de cette base de données. Ceci est accepté uniquement par ICU. Voir Section 23.2.3.4 pour des détails.
fournisseur_locale #
Indique le fournisseur à utiliser pour la collation par défaut dans cette
base. Les valeurs possibles sont : builtin,
icu
(si le serveur a été compilé avec le support d'ICU) ou libc.
Par défaut, le fournisseur est identique à celui de modèle. Voir Section 23.1.4 pour les détails.
version_collation #
Indique la chaîne de version de la collation à enregistrer dans la base.
Normalement, ceci devrait être omis, ce qui fera que la version sera
calculée à partir de la version actuelle de la collation de la base, telle
qu'elle était fournie par le système d'exploitation. Cette option a pour
but d'être utilisée par pg_upgrade en codant la version
d'une installation existante.
Voir aussi ALTER DATABASE pour savoir comment gérer les différences de version dans la collation.
tablespace #
Le nom du tablespace associé à la nouvelle base de
données ou DEFAULT pour le tablespace de
la base de données modèle. Ce tablespace est celui par
défaut pour les objets créés dans cette base de données. Voir
CREATE TABLESPACE
pour plus d'informations.
allowconn #
À false, personne ne peut se connecter à cette base de données. La
valeur par défaut est true, ce qui permet les connexions (sauf
restriction par d'autres mécanismes, comme
GRANT/REVOKE CONNECT).
limite_connexion #Le nombre de connexions concurrentes à la base de données. -1 (valeur par défaut) signifie qu'il n'y a pas de limite.
istemplate #
À true, cette base de données peut être clonée par tout utilisateur
ayant l'attribut CREATEDB ; à false, seuls les
superutilisateurs ou le propriétaire de la base de données peuvent la
cloner.
oid #L'identifiant d'objet à utiliser pour la nouvelle base de données. Si ce paramètre n'est pas spécifié, PostgreSQL choisira automatiquement un OID convenable. Ce paramètre a principalement pour but une utilisation interne par pg_upgrade, et seul pg_upgrade peut indiquer une valeur inférieure à 16384.
L'ordre des paramètres optionnels n'a aucune importance.
La commande CREATE DATABASE ne peut pas être exécutée à l'intérieur d'un
bloc de transactions.
Les erreurs sur la ligne « ne peut initialiser le répertoire de la base de données » (« could not initialize database directory » dans la version originale) sont le plus souvent dues à des droits insuffisants sur le répertoire de données, à un disque plein ou à un autre problème relatif au système de fichiers.
L'instruction
DROP DATABASE
est utilisée pour supprimer la base de données.
Le programme createdb est un enrobage de cette commande fourni par commodité.
Les paramètres de configuration au niveau base de données, configurés avec
ALTER DATABASE)
et les droits sur la base (configurés avec GRANT) ne sont pas copiés à
partir de la base de données modèle.
Bien qu'il soit possible de copier une base de données autre que
template1 en spécifiant son nom comme modèle, cela n'est pas
(encore) prévu comme une fonctionnalité
« COPY DATABASE » d'usage général.
La limitation principale est qu'aucune autre session ne peut être connectée
à la base modèle pendant sa copie. CREATE DATABASE
échouera s'il y a une autre connexion au moment de son exécution ;
sinon, les nouveaux connexions à la base modèle seront verrouillées jusqu'à
la fin de la commande CREATE DATABASE.
La Section 22.3 fournit plus d'informations à ce
sujet.
L'encodage du jeu de caractère spécifié pour la nouvelle base de données
doit être compatible avec les paramètre de locale
(LC_COLLATE et LC_CTYPE).
Si la locale est C (ou de la même façon
POSIX), alors tous les encodages sont autorisés. Pour
d'autres paramètres de locale, il n'y a qu'un encodage qui fonctionnera
correctement. (Néanmoins, sur Windows, l'encodage UTF-8 peut être utilisée
avec toute locale.) CREATE DATABASE
autorisera les superutilisateurs à spécifier l'encodage
SQL_ASCII quelque soit le paramètre locale mais ce
choix devient obsolète et peut occasionner un mauvais comportement des
fonctions sur les chaînes si des données dont l'encodage n'est pas
compatible avec la locale sont stockées dans la base.
Les paramètres d'encodage et de locale doivent correspondre à ceux de la
base modèle, excepté quand la base template0 est utilisée comme modèle. La
raison en est que d'autres bases de données pourraient contenir des données
qui ne correspondent pas à l'encodage indiqué, ou pourraient contenir des
index dont l'ordre de tri est affecté par LC_COLLATE et
LC_CTYPE. Copier ces données peut résulter en une base de
données qui est corrompue suivant les nouveaux paramètres.
template0, par contre, ne contient aucun index pouvant
être affecté par ces paramètres.
Il n'existe actuellement aucune option pour utiliser une locale de base avec
des comparaisons non déterministes (voir CREATE COLLATION pour
une explication). Si c'est nécessaire, alors les collations par colonne
devront être utilisées.
L'option CONNECTION LIMIT n'est qu'approximativement
contraignante ; si deux nouvelles sessions commencent sensiblement en
même temps alors qu'un seul « connecteur » à la base est
disponible, il est possible que les deux échouent. De plus, les
superutilisateurs et les processus worker ne sont pas soumis à cette
limite.
Créer une nouvelle base de données :
CREATE DATABASE lusiadas;
Créer une base de données ventes possédée par l'utilisateur
app_ventes utilisant le tablespace espace_ventes
comme espace par défaut :
CREATE DATABASE ventes OWNER app_ventes TABLESPACE espace_ventes;
Pour créer une base music avec une locale différente :
CREATE DATABASE music
LOCALE 'sv_SE.utf8'
TEMPLATE template0;
Dans cet exemple, la clause TEMPLATE template0 est
nécessaire si la locale spécifiée est différente de celle de
template1. (Sinon, préciser explicitement la locale est
redondant.)
Pour créer une base music2 avec une locale différente et
et un jeu de caractère différent :
+CREATE DATABASE music2
LOCALE 'sv_SE.iso885915'
ENCODING LATIN9
TEMPLATE template0;
La locale et l'encodage spécifiés doivent correspondre, ou une erreur sera levée.
Veuillez noter que les noms de locale sont spécifiques au système d'exploitation, par conséquent la commande précédente pourrait ne pas fonctionner de la même façon partout.
Il n'existe pas d'instruction CREATE DATABASE
dans le standard SQL. Les bases de données sont équivalentes aux
catalogues, dont la création est définie par l'implantation.