En fait, CREATE DATABASE fonctionne en copiant une base de données préexistante. Par défaut, cette commande copie la base de données système standard template1. Ainsi, cette base de données est le « modèle » à partir duquel de nouvelles bases de données sont créées. Si vous ajoutez des objets à template1, ces objets seront copiés dans les bases de données utilisateur créées ultérieurement. Ce comportement permet d'apporter des modifications locales au jeu standard d'objets des bases de données. Par exemple, si vous installez le langage de procédures PL/pgSQL dans template1, celui-ci sera automatiquement disponible dans les bases de données utilisateur sans qu'il soit nécessaire de faire quelque chose de spécial au moment où ces bases de données sont créées.

Il y a une seconde base de données système standard appelée template0. Cette base de données contient les mêmes données que le contenu initial de template1, c'est-à-dire seulement les objets standards prédéfinis dans votre version de PostgreSQL™. template0 ne devrait jamais être modifiée après initdb. En indiquant à CREATE DATABASE de copier template0 au lieu de template1, vous pouvez créer une base de données utilisateur « vierge » qui ne contient aucun des ajouts locaux à template1. Ceci est particulièrement pratique quand on restaure une sauvegarde réalisé avec pg_dump : le script de dump devrait être restauré dans une base de données vierge pour être sûr de recréer le contenu correct de la base de données sauvegardée, sans survenue de conflits avec des objets qui auraient été ajoutés à template1.

Pour créer une base de données à partir de template0, utilisez

CREATE DATABASE nom_base TEMPLATE template0;

dans l'environnement SQL ou

createdb -T template0 nom_base

dans le shell.

Il est possible de créer des bases de données modèles supplémentaires et, à vrai dire, on peut copier n'importe quelle base de données d'un cluster en la désignant comme modèle pour la commande CREATE DATABASE. Cependant, il importe de comprendre, que ceci n'est pas (encore) à prendre comme une commande « COPY DATABASE » de portée générale. En particulier, il est essentiel que la base de données source soit inactive (pas de transactions en écriture en cours) pendant toute la durée de l'opération de copie. CREATE DATABASE vérifie qu'aucune autre session que la sienne n'est connectée à la base de données source au début de l'opération mais ceci ne garantie pas que des changements ne peuvent pas être effectués pendant le déroulement de la copie, ce qui aboutirait à une base de données copiée incohérente. C'est pourquoi nous recommandons que les bases de données utilisées comme modèles soient mises en lecture seule.

Deux drapeaux utiles existent dans pg_database pour chaque base de données : les colonnes datistemplate et datallowconn. datistemplate peut être positionné à vrai pour indiquer qu'une base de données a vocation à servir de modèle à CREATE DATABASE. Si ce drapeau est positionné à vrai, la base de données peut être clonée par tout utilisateur ayant le droit CREATEDB ; s'il est positionné à faux, seuls les super-utilisateurs et le propriétaire de la base de données peuvent la cloner. Si datallowconn est positionné à faux, alors aucune nouvelle connexion à cette base de données n'est autorisée (mais les sessions existantes ne sont pas tuées simplement en positionnant ce drapeau à faux). La base de données template0 est normalement marquée datallowconn = false pour empêcher qu'elle ne soit modifiée. Aussi bien template0 que template1 devraient toujours être marquées datistemplate = true.

Après avoir préparé ou modifé une base de données modèle, exécuter les commandes VACUUM FREEZE dans cette base de données est une bonne idée. Si cela se fait alors qu'il n'y a pas d'autre transaction ouverte dans la même base de données, alors il est garanti que toutes les lignes de la base de données seront « gelées » et ne seront pas sujettes à des problèmes de réutilisation d'ID de transaction déjà attribués. C'est particulièrement important pour une base de données qui aura le drapeau datallowconn positionné à faux puisqu'il sera impossible d'effectuer les VACUUM de maintenance sur une telle base de données. Voir la Section 22.1.3, « Éviter les cycles des identifiants de transactions » pour plus d'informations.