Changeset 61

Show
Ignore:
Timestamp:
11/07/05 09:20:07 (3 years ago)
Author:
gleu
Message:

Mise à jour vers un semblant de RC2 qui ressemble furieusement à une version finale :-D

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/sgml/array.sgml

    r35 r61  
    6565 
    6666 <para> 
    67   Une autre syntaxe, conforme au standard SQL:2003, pourrait être 
     67  Une autre syntaxe, conforme au standard SQL, pourrait être 
    6868  utilisée pour les tableaux à une dimension. 
    6969  <structfield>paye_par_semaine</structfield> pourrait avoir été définie ainsi&nbsp;: 

  • traduc/trunk/sgml/backup.sgml

    r48 r61  
    12391239    significativement le volume total des traces archivées en désactivat les 
    12401240    images de page grâce au paramètre <xref linkend="guc-full-page-writes"> 
    1241     (lire les notes et avertissements dans <xref linkend="reliability"> avant 
     1241    (lire les notes et avertissements dans <xref linkend="wal"> avant 
    12421242    de le faire). Désactiver les images de page n'empêche pas l'utilisation des 
    12431243    traces pour les opérations PITR. Un développement possible serait de 

  • traduc/trunk/sgml/config.sgml

    r58 r61  
    488488      <listitem> 
    489489       <para> 
    490         Sur les systèmes supportant l'option socket TCP_KEEPIDLE, spécifie le 
    491         nombre de secondes entre l'envoi de signaux <quote>keepalives</quote> 
    492         sur une connexion restant silencieuse. Une valeur de 0 permet d'utiliser 
    493         la valeur par défaut du système. Si TCP_KEEPIDLE n'est pas supporté, ce 
    494         paramètre doit valoir 0. Cette option est ignorée pour les connexions 
    495         réalisées via un socket de domaine Unix. 
     490        Sur les systèmes supportant l'option socket <symbol>TCP_KEEPIDLE<symbol>, 
     491        spécifie le nombre de secondes entre l'envoi de signaux 
     492        <quote>keepalives</quote> sur une connexion restant silencieuse. Une 
     493        valeur de 0 permet d'utiliser la valeur par défaut du système. Si 
     494        <symbol>TCP_KEEPIDLE</symbol> n'est pas supporté, ce paramètre doit 
     495        valoir 0. Cette option est ignorée pour les connexions réalisées via un 
     496        socket de domaine Unix. 
    496497       </para> 
    497498      </listitem> 
    …… 
    505506      <listitem> 
    506507       <para> 
    507         Sur les systèmes supportant l'option socket TCP_KEEPINTVL, spécifie 
    508         le temps, en seconde, à attendre une réponse à un <quote>keepalive</quote> 
    509         avant de retransmettre. Une valeur de 0 permet d'utiliser la valeur 
    510         par défaut du système. Si TCP_KEEPINTVL n'est pas supporté, ce paramètre 
    511         doit valoir 0. Cette option est ignorée pour les connexions réalisées 
    512         via un socket de domaine Unix. 
     508        Sur les systèmes supportant l'option socket <symbol>TCP_KEEPINTVL</symbol>, 
     509        spécifie le temps, en seconde, à attendre une réponse à un 
     510        <quote>keepalive</quote> avant de retransmettre. Une valeur de 0 permet 
     511        d'utiliser la valeur par défaut du système. Si <symbol>TCP_KEEPINTVL</symbol> 
     512        n'est pas supporté, ce paramètre doit valoir 0. Cette option est ignorée 
     513        pour les connexions réalisées via un socket de domaine Unix. 
    513514       </para> 
    514515      </listitem> 
    …… 
    522523      <listitem> 
    523524       <para> 
    524         Sur les systèmes supportant l'option socket TCP_KEEPCNT, spécifie 
    525         combien de <quote>keepalive</quote> peuvent être perdus avant de 
    526         considérer la connexion comme perdue. Une valeur de 0 permet d'utiliser la valeur 
    527         par défaut du système. Si TCP_KEEPCNT n'est pas supporté, ce paramètre 
    528         doit valoir 0. Cette option est ignorée pour les connexions réalisées 
    529         via un socket de domaine Unix. 
     525        Sur les systèmes supportant l'option socket <symbol>TCP_KEEPCNT</symbol>, 
     526        spécifie combien de <quote>keepalive</quote> peuvent être perdus avant 
     527        de considérer la connexion comme perdue. Une valeur de 0 permet d'utiliser 
     528        la valeur par défaut du système. Si <symbol>TCP_KEEPCNT</symbol> n'est 
     529        pas supporté, ce paramètre doit valoir 0. Cette option est ignorée pour 
     530        les connexions réalisées via un socket de domaine Unix. 
    530531       </para> 
    531532      </listitem> 
    …… 
    20752076       <para> 
    20762077        Active ou désactive l'utilisation à la table des contraintes par le 
    2077         planificateur des requêtes pour limiter l'accès aux tables. Désactivé 
     2078        planificateur des requêtes pour optimiser les requêtes. Désactivé 
    20782079        par défaut (<literal>off</>). 
    20792080       </para> 
    …… 
    20812082       <para> 
    20822083        Quand ce paramètre est activé (<literal>on</>), le planificateur compare 
    2083         les conditions de la requête avec les contraintes CHECK de la table et 
    2084         omet de parcourir les tables dont les conditions sont en contradiction 
    2085         avec les contraintes. (Actuellement, ceci se fait seulement pour les 
    2086         tables filles des parcours d'héritage.) Par exemple&nbsp;: 
     2084        les conditions de la requête avec les contraintes <literal>CHECK</> de 
     2085        la table et omet de parcourir les tables dont les conditions sont en 
     2086        contradiction avec les contraintes (actuellement, ceci se fait seulement 
     2087        pour les tables filles des parcours d'héritage). Par exemple&nbsp;: 
    20872088 
    20882089<programlisting> 
    …… 
    20942095</programlisting> 
    20952096 
    2096         Avec l'activation de l'exclusion de la contrainte, ce SELECT ne parcourira 
    2097         pas du tout <structname>fils1000</>. Ceci peut améliorer les performances 
    2098         quand l'héritage est utilisé pour construire des tables partitionnées. 
     2097        Avec l'activation de l'exclusion de la contrainte, ce <command>SELECT</> 
     2098        ne parcourira pas du tout <structname>fils1000</>. Ceci peut améliorer 
     2099        les performances quand l'héritage est utilisé pour construire des tables 
     2100        partitionnées. 
    20992101       </para> 
    21002102 
    …… 
    21122114        l'activer seulement si vous utilisez réellement des tables partitionées 
    21132115        conçues pour prendre tout l'avantage de cette fonctionnalité. 
     2116       </para> 
     2117 
     2118       <para> 
     2119        Référez-vous à <xref linkend="ddl-partitioning"> pour plus d'informations 
     2120        sur l'utilisation des exclusion de contraintes et du partitionement. 
    21142121       </para> 
    21152122      </listitem> 

  • traduc/trunk/sgml/cvs.sgml

    r39 r61  
    117117    <filename>pgsql</filename> et lancez la commande 
    118118     <programlisting> 
    119 $ cvs -z3 update -d -P 
     119cvs -z3 update -d -P 
    120120     </programlisting> 
    121121 
    …… 
    140140     qu'à lancer 
    141141     <programlisting> 
    142 $ cvs update 
     142cvs update 
    143143     </programlisting> 
    144144 
    …… 
    194194 
    195195   <programlisting> 
    196 $ cvs checkout -r REL6_4 tc 
     196cvs checkout -r REL6_4 tc 
    197197   </programlisting> 
    198198   C'est en particulier utile si quelqu'un pense qu'il y a un problème 
    …… 
    240240 
    241241   <programlisting> 
    242 $ cd pgsql 
    243 $ cvs tag -b REL6_4 
     242cd pgsql 
     243cvs tag -b REL6_4 
    244244   </programlisting> 
    245245   ce qui créera la marque et la branche pour l'arbre de la version. 
    …… 
    276276 
    277277   <programlisting> 
    278 $ cvs checkout -r REL6_4 
     278cvs checkout -r REL6_4 
    279279   </programlisting> 
    280280 
    …… 
    357357 
    358358    <programlisting> 
    359 $ cvs init 
     359cvs init 
    360360    </programlisting> 
    361361 
    …… 
    386386 
    387387    <programlisting> 
    388 $ cvsup -L 2 <replaceable class="parameter">postgres.cvsup</replaceable> 
     388cvsup -L 2 <replaceable class="parameter">postgres.cvsup</replaceable> 
    389389    </programlisting> 
    390390 
    …… 
    576576 
    577577        <programlisting> 
    578 $ cd /usr/local/bin 
    579 $ tar zxvf /usr/local/src/cvsup-16.0-linux-i386.tar.gz 
    580 $ mv cvsup.1 ../doc/man/man1/ 
     578cd /usr/local/bin 
     579tar zxvf /usr/local/src/cvsup-16.0-linux-i386.tar.gz 
     580mv cvsup.1 ../doc/man/man1/ 
    581581        </programlisting> 
    582582       </para> 
    …… 
    717717 </sect1> 
    718718</appendix> 
    719  
    720  
    721 <!-- Keep this comment at the end of the file 
    722 Local variables: 
    723 mode:sgml 
    724 sgml-omittag:nil 
    725 sgml-shorttag:t 
    726 sgml-minimize-attributes:nil 
    727 sgml-always-quote-attributes:t 
    728 sgml-indent-step:1 
    729 sgml-indent-data:t 
    730 sgml-parent-document:nil 
    731 sgml-default-dtd-file:"./reference.ced" 
    732 sgml-exposed-tags:nil 
    733 sgml-local-catalogs:("/usr/lib/sgml/catalog") 
    734 sgml-local-ecat-files:nil 
    735 End: 
    736 --> 

  • traduc/trunk/sgml/ddl.sgml

    r48 r61  
    1212  Ensuite, nous discuterons de l'organisation des tables dans les schémas, et de 
    1313  l'attribution de droits aux tables. Enfin, 
    14   nous verrons brièvement d'autres fonctionnalités, tel que les vues, les fonctions 
    15   et les déclencheurs. 
     14  nous verrons brièvement d'autres fonctionnalités, tel que l'héritage, les vues, 
     15  les fonctions et les déclencheurs. 
    1616 </para> 
    1717 
    …… 
    207207   sera évaluée à l'insertion de la valeur par défaut 
    208208   (<emphasis>pas</emphasis> à la création de la table.) Un exemple habituel 
    209    est qu'une colonne de type timestamp pourrait avoir <literal>now()</> comme 
    210    valeur par défaut de façon à ce qu'elle obtienne la valeur de l'heure au 
    211    moment de l'insertion. Un autre exemple habituel est la génération d'un 
    212    <quote>numéro de série</> pour chaque ligne. 
     209   est qu'une colonne de type <type>timestamp</type> pourrait avoir 
     210   <literal>now()</> comme valeur par défaut de façon à ce qu'elle obtienne la 
     211   valeur de l'heure au moment de l'insertion. Un autre exemple habituel est 
     212   la génération d'un <quote>numéro de série</> pour chaque ligne. 
    213213   Dans <productname>PostgreSQL</productname>, ceci se fait habituellement par 
    214214   quelque chose comme 
    …… 
    411411    contient pas de valeurs NULL, la contrainte non-NULL décrite 
    412412    dans la section suivante peut être utilisée. 
     413   </para> 
     414 
     415   <para> 
     416    Les contraintes de vérification sont utiles pour améliorer la performance 
     417    des tables partitionées. Pour les détails, voir 
     418    <xref linkend="ddl-partitioning">. 
    413419   </para> 
    414420  </sect2> 
    …… 
    904910        L' OID de la table contenant cette ligne. Cette colonne est 
    905911        particulièrement utile pour les requêtes qui font des sélections à 
    906         partir de hiérarchies héritées puisque, sans elle, il est difficile de 
     912        partir de hiérarchies héritées (voir <xref linkend="ddl-inherit">) 
     913        puisque, sans elle, il est difficile de 
    907914        dire de quelle table provient une ligne. <structfield>tableoid</structfield> 
    908915        peut être joint à la colonne <structfield>oid</structfield> de 
    …… 
    10551062</sect1> 
    10561063 
    1057  <sect1 id="ddl-inherit"> 
    1058   <title>Héritage</title> 
    1059  
    1060   <remark>Cette section doit être repensée. Une partie de cette 
    1061   information doit aller dans les chapitres suivants.</remark> 
    1062  
    1063   <para> 
    1064    Créons deux tables. La table capitales contient les capitales 
    1065    d'état qui sont aussi des villes. Naturellement, la table 
    1066    capitales doit hériter de la table villes. 
    1067  
    1068 <programlisting> 
    1069 CREATE TABLE villes ( 
    1070     nom             text, 
    1071     population      float, 
    1072     altitude        int     -- (in ft) 
    1073 ); 
    1074  
    1075 CREATE TABLE capitales ( 
    1076     etat           char(2) 
    1077 ) INHERITS (villes); 
    1078 </programlisting> 
    1079  
    1080    Dans ce cas, une ligne de la table capitales <firstterm>hérite</firstterm> 
    1081    de tous les attributs (nom,  population et altitude) de son parent 
    1082    villes. Les capitales d'état ont un attribut supplémentaire <quote>etat</quote> 
    1083    qui indique leur état. Dans <productname>PostgreSQL</productname>, 
    1084    une table peut hériter de zéro tables ou plus et une requête peut référencer 
    1085    toutes les lignes d'une table ou toutes les lignes d'une table avec celles de 
    1086    ses descendants. 
    1087  
    1088    <note> 
    1089     <para> 
    1090      La hiérarchie d'héritage est en fait un graphe acyclique dirigé. 
    1091     </para> 
    1092    </note> 
    1093   </para> 
    1094  
    1095   <para> 
    1096     Par exemple, la requête suivante cherche les noms de toutes les villes, 
    1097     y compris les capitales d'état, qui se situent à une altitude de plus 
    1098     de 500 pieds&nbsp;: 
    1099  
    1100 <programlisting> 
    1101 SELECT nom, altitude 
    1102     FROM villes 
    1103     WHERE altitude &gt; 500; 
    1104 </programlisting> 
    1105  
    1106    qui retourne&nbsp;: 
    1107  
    1108 <programlisting> 
    1109    nom     | altitude 
    1110 -----------+---------- 
    1111  Las Vegas |     2174 
    1112  Mariposa  |     1953 
    1113  Madison   |      845 
    1114 </programlisting> 
    1115   </para> 
    1116  
    1117   <para> 
    1118     D'un autre côté, la requête suivante cherche toutes 
    1119     les villes qui ne sont pas des capitales d'état et 
    1120     qui sont situés à une altitude de plus de 500 pieds: 
    1121  
    1122 <programlisting> 
    1123 SELECT nom, altitude 
    1124     FROM ONLY villes 
    1125     WHERE altitude &gt; 500; 
    1126  
    1127    nom     | altitude 
    1128 -----------+---------- 
    1129  Las Vegas |     2174 
    1130  Mariposa  |     1953 
    1131 </programlisting>          
    1132   </para> 
    1133  
    1134   <para> 
    1135    Ici, le <quote>ONLY</quote> avant villes indique que la requête ne doit 
    1136    être exécutée que sur villes et non les tables en dessous de villes dans la 
    1137    hiérarchie d'héritage. Beaucoup des commandes dont nous avons déjà discutées 
    1138    -- <command>SELECT</command>, <command>UPDATE</command> et <command>DELETE</command> -- 
    1139    gèrent cette syntaxe <quote>ONLY</quote>. 
    1140   </para> 
    1141  
    1142   <note> 
    1143     <title>Héritages et droits</title> 
    1144     <para> 
    1145      Comme les droits ne sont pas hérités automatiquement, un utilisateur 
    1146      tentant d'accéder à une table parent doit soit avoir au moins les mêmes 
    1147      droits que sur la table fille soit avoir utiliser la notation 
    1148      <quote>ONLY</quote>. Si vous devez créer une nouvelle relation d'héritage 
    1149      dans un système existant, faites bien attention à ce que cela ne vous pose 
    1150      pas de problème. 
    1151     </para> 
    1152   </note> 
    1153  
    1154   <note> 
    1155     <title>Obsolète</title>  
    1156     <para> 
    1157      Dans les versions précédentes de <productname>PostgreSQL</productname>, 
    1158      le comportement par défaut était de ne pas inclure les tables enfants 
    1159      dans les requêtes. Il a été prouvé que cela amenait facilement des 
    1160      erreurs et étant aussi en violation du standard SQL:2003. Avec l'ancienne 
    1161      syntaxe, pour obtenir les sous-tables, vous ajoutez 
    1162       <literal>*</literal> au nom de la table. Par exemple 
    1163       <programlisting> 
    1164         SELECT * from villes*; 
    1165       </programlisting> 
    1166       Vous pouvez toujours spécifier explicitement le parcours des tables 
    1167       enfants en ajoutant <literal>*</literal>, ainsi que spécifier 
    1168       explicitement les tables enfants en écrivant <quote>ONLY</quote>. Mais, 
    1169       depuis la version 7.1, le comportement par défaut pour un nom de table 
    1170       non décoré est de parcourir aussi ses tables enfants. Pour obtenir l'ancien 
    1171       comportement par défaut, initialisez l'option de configuration 
    1172       <literal>SQL_Inheritance</literal> à off, ainsi 
    1173       <programlisting> 
    1174         SET SQL_Inheritance TO OFF; 
    1175       </programlisting> 
    1176       ou ajoutez une ligne dans votre fichier 
    1177       <filename>postgresql.conf</filename>. 
    1178     </para> 
    1179   </note> 
    1180  
    1181   <para> 
    1182   Dans certain cas, vous souhaitez savoir de quelle table provient une ligne 
    1183   donnée. Une colonne système appelée <structfield>TABLEOID</structfield> 
    1184   présente dans chaque table vous donne la table d'origine&nbsp;: 
    1185  
    1186 <programlisting> 
    1187 SELECT c.tableoid, c.nom, c.altitude 
    1188 FROM villes c 
    1189 WHERE c.altitude &gt; 500; 
    1190 </programlisting> 
    1191  
    1192    qui renvoie&nbsp;: 
    1193  
    1194 <programlisting> 
    1195  tableoid |   nom    | altitude 
    1196 ----------+-----------+---------- 
    1197    139793 | Las Vegas |     2174 
    1198    139793 | Mariposa  |     1953 
    1199    139798 | Madison   |      845 
    1200 </programlisting> 
    1201  
    1202    (Si vous essayez de reproduire cet exemple, vous obtiendrez probablement des 
    1203    OID numériques différents). En faisant une jointure avec 
    1204    <structname>pg_class</structname>, vous pourrez voir les noms de tables 
    1205    actuelles&nbsp;: 
    1206  
    1207 <programlisting> 
    1208 SELECT p.relname, v.nom, v.altitude 
    1209 FROM villes v, pg_class p 
    1210 WHERE v.altitude &gt; 500 and v.tableoid = p.oid; 
    1211 </programlisting> 
    1212  
    1213    ce qui retourne&nbsp;: 
    1214  
    1215 <programlisting> 
    1216  relname   |   nom     | altitude 
    1217 -----------+-----------+---------- 
    1218  villes    | Las Vegas |     2174 
    1219  villes    | Mariposa  |     1953 
    1220  capitales | Madison   |      845 
    1221 </programlisting> 
    1222     
    1223   </para> 
    1224  
    1225   <para> 
    1226    Une table peut très bien hériter de plusieurs tables. Dans ce cas, 
    1227    les colonnes de la table fille correspondent à l'union des colonnes provenant 
    1228    des tables parentes et des colonnes définies dans la table fille. 
    1229   </para> 
    1230  
    1231   <para> 
    1232     Une limitation sérieuse de la fonctionnalité d'héritage est que les index 
    1233     (incluant les contraintes uniques) et les contraintes de clés étrangères 
    1234     s'appliquent seulement à des tables seules, pas à leurs héritiers. Ceci 
    1235     est vrai pour le côté de référence et le côté référencé d'une contrainte 
    1236     de clé étrangère. Du coup, dans les termes de l'exemple ci-dessus&nbsp;: 
    1237  
    1238     <itemizedlist> 
    1239       <listitem> 
    1240         <para> 
    1241           Si nous déclarons <structname>villes</>.<structfield>nom</> comme 
    1242            <literal>UNIQUE</> ou comme une clé primaire (<literal>PRIMARY 
    1243            KEY</>), ceci 
    1244            n'empêchera pas la table <structname>capitales</> d'avoir des lignes 
    1245            avec des noms dupliqués dans <structname>villes</>. Et ces lignes 
    1246            dupliquées pourraient par défaut s'afficher dans les requêtes sur 
    1247            <structname>villes</>. En fait, par défaut, 
    1248            <structname>capitales</> n'aurait pas du tout de contrainte 
    1249            unique et, du coup, pourrait contenir plusieurs lignes avec le 
    1250            même nom. Vous pouvez ajouter une contrainte unique à 
    1251            <structname>capitales</> mais ceci n'empêcherait pas la duplication 
    1252            comparée à <structname>villes</>. 
    1253         </para> 
    1254       </listitem> 
    1255  
    1256       <listitem> 
    1257         <para> 
    1258           De façon similaire, si nous devions spécifier que 
    1259           <structname>villes</>.<structfield>nom</> fait référence 
    1260           (<literal>REFERENCES</>) une autre table, cette contrainte ne serait 
    1261           pas automatiquement propager à <structname>capitales</>. Dans ce cas, 
    1262           vous pourriez contourner ceci en ajoutant manuellement la même 
    1263           contrainte <literal>REFERENCES</> à <structname>capitales</>. 
    1264         </para> 
    1265       </listitem> 
    1266  
    1267       <listitem> 
    1268         <para> 
    1269           Spécifier que la colonne d'une autre table <literal>REFERENCES 
    1270           villes(nom)</> autoriserait l'autre table à contenir les noms des 
    1271           villes mais pas les noms des capitales. Il n'existe pas de bons 
    1272           contournements pour ce cas. 
    1273         </para> 
    1274       </listitem> 
    1275     </itemizedlist> 
    1276  
    1277     Ces déficiences seront probablement corrigées dans une version future mais 
    1278     en attendant, un soucis considérable est nécessaire dans la décision de 
    1279     l'utilité de l'héritage pour votre problème. 
    1280   </para> 
    1281  </sect1> 
    1282  
    12831064 <sect1 id="ddl-alter"> 
    12841065  <title>Modification des tables</title> 
    …… 
    17301511 
    17311512   <para> 
    1732     Pour créer un schéma, utilisez la commande <literal>CREATE 
    1733     SCHEMA</literal>. Donnez au schéma un nom de votre choix. Par 
     1513    Pour créer un schéma, utilisez la commande <command>CREATE 
     1514    SCHEMA</command>. Donnez au schéma un nom de votre choix. Par 
    17341515    exemple&nbsp;: 
    17351516<programlisting> 
    …… 
    21301911 </sect1> 
    21311912 
     1913 <sect1 id="ddl-inherit"> 
     1914  <title>Héritage</title> 
     1915 
     1916  <indexterm> 
     1917   <primary>inheritance</primary> 
     1918  </indexterm> 
     1919 
     1920  <indexterm> 
     1921   <primary>table</primary> 
     1922   <secondary>inheritance</secondary> 
     1923  </indexterm> 
     1924 
     1925  <para> 
     1926   <productname>PostgreSQL</productname> implements table inheritance 
     1927   which can be a useful tool for database designers.  (SQL:1999 and 
     1928   later define a type inheritance feature, which differs in many 
     1929   respects from the features described here.) 
     1930  </para> 
     1931 
     1932  <para> 
     1933   Let's start with an example: suppose we are trying to build a data 
     1934   model for cities.  Each state has many cities, but only one 
     1935   capital. We want to be able to quickly retrieve the capital city 
     1936   for any particular state. This can be done by creating two tables, 
     1937   one for state capitals and one for cities that are not 
     1938   capitals. However, what happens when we want to ask for data about 
     1939   a city, regardless of whether it is a capital or not? The 
     1940   inheritance feature can help to resolve this problem. We define the 
     1941   <structname>capitals</structname> table so that it inherits from 
     1942   <structname>cities</structname>: 
     1943 
     1944<programlisting> 
     1945CREATE TABLE villes ( 
     1946    nom             text, 
     1947    population      float, 
     1948    altitude        int     -- (en pied) 
     1949); 
     1950 
     1951CREATE TABLE capitales ( 
     1952    etat           char(2) 
     1953) INHERITS (villes); 
     1954</programlisting> 
     1955 
     1956   In this case, the <structname>capitals</> table <firstterm>inherits</> 
     1957   all the columns of its parent table, <structname>cities</>. State 
     1958   capitals also have an extra column, <structfield>state</>, that shows 
     1959   their state. 
     1960  </para> 
     1961 
     1962  <para> 
     1963   In <productname>PostgreSQL</productname>, a table can inherit from 
     1964   zero or more other tables, and a query can reference either all 
     1965   rows of a table or all rows of a table plus all of its descendant tables. 
     1966   The latter behavior is the default. 
     1967   For example, the following query finds the names of all cities, 
     1968   including state capitals, that are located at an altitude over 
     1969   500ft: 
     1970 
     1971<programlisting> 
     1972SELECT nom, altitude 
     1973    FROM villes 
     1974    WHERE altitude &gt; 500; 
     1975</programlisting> 
     1976 
     1977   Given the sample data from the <productname>PostgreSQL</productname> 
     1978   tutorial (see <xref linkend="tutorial-sql-intro">), this returns: 
     1979 
     1980<programlisting> 
     1981   nom     | altitude 
     1982-----------+---------- 
     1983 Las Vegas |     2174 
     1984 Mariposa  |     1953 
     1985 Madison   |      845 
     1986</programlisting> 
     1987  </para> 
     1988 
     1989  <para> 
     1990   On the other hand, the following query finds all the cities that 
     1991   are not state capitals and are situated at an altitude over 500ft: 
     1992 
     1993<programlisting> 
     1994SELECT nom, altitude 
     1995    FROM ONLY villes 
     1996    WHERE altitude &gt; 500; 
     1997 
     1998   nom     | altitude 
     1999-----------+---------- 
     2000 Las Vegas |     2174 
     2001 Mariposa  |     1953 
     2002</programlisting> 
     2003  </para> 
     2004 
     2005  <para> 
     2006   Here the <literal>ONLY</literal> keyword indicates that the query 
     2007   should apply only to <structname>cities</structname>, and not any tables 
     2008   below <structname>cities</structname> in the inheritance hierarchy.  Many 
     2009   of the commands that we have already discussed &mdash; 
     2010   <command>SELECT</command>, <command>UPDATE</command> and 
     2011   <command>DELETE</command> &mdash; support the 
     2012   <literal>ONLY</literal> keyword. 
     2013  </para> 
     2014 
     2015  <para> 
     2016  Dans certain cas, vous souhaitez savoir de quelle table provient une ligne 
     2017  donnée. Une colonne système appelée <structfield>TABLEOID</structfield> 
     2018  présente dans chaque table vous donne la table d'origine&nbsp;: 
     2019 
     2020<programlisting> 
     2021SELECT c.tableoid, c.nom, c.altitude 
     2022FROM villes c 
     2023WHERE c.altitude &gt; 500; 
     2024</programlisting> 
     2025 
     2026   qui renvoie&nbsp;: 
     2027 
     2028<programlisting> 
     2029 tableoid |   nom    | altitude 
     2030----------+-----------+---------- 
     2031   139793 | Las Vegas |     2174 
     2032   139793 | Mariposa  |     1953 
     2033   139798 | Madison   |      845 
     2034</programlisting> 
     2035 
     2036   (Si vous essayez de reproduire cet exemple, vous obtiendrez probablement des 
     2037   OID numériques différents). En faisant une jointure avec 
     2038   <structname>pg_class</structname>, vous pourrez voir les noms de tables 
     2039   actuelles&nbsp;: 
     2040 
     2041<programlisting> 
     2042SELECT p.relname, v.nom, v.altitude 
     2043FROM villes v, pg_class p 
     2044WHERE v.altitude &gt; 500 and v.tableoid = p.oid; 
     2045</programlisting> 
     2046 
     2047   ce qui retourne&nbsp;: 
     2048 
     2049<programlisting> 
     2050 relname   |   nom     | altitude 
     2051-----------+-----------+---------- 
     2052 villes    | Las Vegas |     2174 
     2053 villes    | Mariposa  |     1953 
     2054 capitales | Madison   |      845 
     2055</programlisting> 
     2056    
     2057  </para> 
     2058 
     2059  <para> 
     2060   Inheritance does not automatically propagate data from 
     2061   <command>INSERT</command> or <command>COPY</command> commands to 
     2062   other tables in the inheritance hierarchy. In our example, the 
     2063   following <command>INSERT</command> statement will fail: 
     2064<programlisting> 
     2065INSERT INTO cities (name, population, altitude, state) 
     2066VALUES ('New York', NULL, NULL, 'NY'); 
     2067</programlisting> 
     2068   We might hope that the data would somehow be routed to the 
     2069   <structname>capitals</structname> table, but this does not happen: 
     2070   <command>INSERT</command> always inserts into exactly the table 
     2071   specified.  In some cases it is possible to redirect the insertion 
     2072   using a rule (see <xref linkend="rules">).  However that does not 
     2073   help for the above case because the <structname>cities</> table 
     2074   does not contain the column <structfield>state</>, and so the 
     2075   command will be rejected before the rule can be applied. 
     2076  </para> 
     2077 
     2078  <para> 
     2079   Check constraints can be defined on tables within an inheritance 
     2080   hierarchy. All check constraints on a parent table are 
     2081   automatically inherited by all of its children.  Other types of 
     2082   constraints are not inherited, however. 
     2083  </para> 
     2084 
     2085  <para> 
     2086   A table can inherit from more than one parent table, in which case it has 
     2087   the union of the columns defined by the parent tables.  Any columns 
     2088   declared in the child table's definition are added to these.  If the 
     2089   same column name appears in multiple parent tables, or in both a parent 
     2090   table and the child's definition, then these columns are <quote>merged</> 
     2091   so that there is only one such column in the child table.  To be merged, 
     2092   columns must have the same data types, else an error is raised.  The 
     2093   merged column will have copies of all the check constraints coming from 
     2094   any one of the column definitions it came from. 
     2095  </para> 
     2096 
     2097  <para> 
     2098   Table inheritance can currently only be defined using the <xref 
     2099   linkend="sql-createtable" endterm="sql-createtable-title"> 
     2100   statement.  The related statement <command>CREATE TABLE AS</command> does 
     2101   not allow inheritance to be specified. There 
     2102   is no way to add an inheritance link to make an existing table into 
     2103   a child table. Similarly, there is no way to remove an inheritance 
     2104   link from a child table once it has been defined, other than by dropping 
     2105   the table completely.  A parent table cannot be dropped 
     2106   while any of its children remain. If you wish to remove a table and 
     2107   all of its descendants, one easy way is to drop the parent table with 
     2108   the <literal>CASCADE</literal> option. 
     2109  </para> 
     2110 
     2111  <para> 
     2112   <xref linkend="sql-altertable" endterm="sql-altertable-title"> will 
     2113   propagate any changes in column data definitions and check 
     2114   constraints down the inheritance hierarchy.  Again, dropping 
     2115   columns or constraints on parent tables is only possible when using 
     2116   the <literal>CASCADE</literal> option. <command>ALTER 
     2117   TABLE</command> follows the same rules for duplicate column merging 
     2118   and rejection that apply during <command>CREATE TABLE</command>. 
     2119  </para> 
     2120 
     2121 <sect2 id="ddl-inherit-caveats"> 
     2122  <title>Caveats</title> 
     2123 
     2124  <para> 
     2125   Table access permissions are not automatically inherited.  Therefore, 
     2126   a user attempting to access a parent table must either have permissions 
     2127   to do the operation on all its child tables as well, or must use the 
     2128   <literal>ONLY</literal> notation.  When adding a new child table to 
     2129   an existing inheritance hierarchy, be careful to grant all the needed 
     2130   permissions on it. 
     2131  </para> 
     2132 
     2133  <para> 
     2134    Une limitation sérieuse de la fonctionnalité d'héritage est que les index 
     2135    (incluant les contraintes uniques) et les contraintes de clés étrangères 
     2136    s'appliquent seulement à des tables seules, pas à leurs héritiers. Ceci 
     2137    est vrai pour le côté de référence et le côté référencé d'une contrainte 
     2138    de clé étrangère. Du coup, dans les termes de l'exemple ci-dessus&nbsp;: 
     2139 
     2140    <itemizedlist> 
     2141      <listitem> 
     2142        <para> 
     2143          Si nous déclarons <structname>villes</>.<structfield>nom</> comme 
     2144           <literal>UNIQUE</> ou comme une clé primaire (<literal>PRIMARY 
     2145           KEY</>), ceci 
     2146           n'empêchera pas la table <structname>capitales</> d'avoir des lignes 
     2147           avec des noms dupliqués dans <structname>villes</>. Et ces lignes 
     2148           dupliquées pourraient par défaut s'afficher dans les requêtes sur 
     2149           <structname>villes</>. En fait, par défaut, 
     2150           <structname>capitales</> n'aurait pas du tout de contrainte 
     2151           unique et, du coup, pourrait contenir plusieurs lignes avec le 
     2152           même nom. Vous pouvez ajouter une contrainte unique à 
     2153           <structname>capitales</> mais ceci n'empêcherait pas la duplication 
     2154           comparée à <structname>villes</>. 
     2155        </para> 
     2156      </listitem> 
     2157 
     2158      <listitem> 
     2159        <para> 
     2160          De façon similaire, si nous devions spécifier que 
     2161          <structname>villes</>.<structfield>nom</> fait référence 
     2162          (<literal>REFERENCES</>) une autre table, cette contrainte ne serait 
     2163          pas automatiquement propager à <structname>capitales</>. Dans ce cas, 
     2164          vous pourriez contourner ceci en ajoutant manuellement la même 
     2165          contrainte <literal>REFERENCES</> à <structname>capitales</>. 
     2166        </para> 
     2167      </listitem> 
     2168 
     2169      <listitem> 
     2170        <para> 
     2171          Spécifier que la colonne d'une autre table <literal>REFERENCES 
     2172          villes(nom)</> autoriserait l'autre table à contenir les noms des 
     2173          villes mais pas les noms des capitales. Il n'existe pas de bons 
     2174          contournements pour ce cas. 
     2175        </para> 
     2176      </listitem> 
     2177    </itemizedlist> 
     2178 
     2179    Ces déficiences seront probablement corrigées dans une version future mais 
     2180    en attendant, un soucis considérable est nécessaire dans la décision de 
     2181    l'utilité de l'héritage pour votre problème. 
     2182  </para> 
     2183 
     2184  <note> 
     2185   <title>Deprecated</title> 
     2186   <para> 
     2187     In previous versions of <productname>PostgreSQL</productname>, the 
     2188     default behavior was not to include child tables in queries. This was 
     2189     found to be error prone and is also in violation of the SQL 
     2190     standard. Under the old syntax, to include the child tables you append 
     2191     <literal>*</literal> to the table name. For example: 
     2192<programlisting> 
     2193SELECT * from cities*; 
     2194</programlisting> 
     2195     You can still explicitly specify scanning child tables by 
     2196     appending <literal>*</literal>, as well as explicitly specify not 
     2197     scanning child tables by writing <literal>ONLY</literal>.  But 
     2198     beginning in version 7.1, the default behavior for an undecorated 
     2199     table name is to scan its child tables too, whereas before the 
     2200     default was not to do so.  To get the old default behavior, 
     2201     disable the <xref linkend="guc-sql-inheritance"> configuration 
     2202     option. 
     2203   </para> 
     2204  </note> 
     2205 
     2206   </sect2> 
     2207  </sect1> 
     2208 
     2209  <sect1 id="ddl-partitioning"> 
     2210   <title>Partitioning</title> 
     2211 
     2212   <indexterm> 
     2213    <primary>partitioning</primary> 
     2214   </indexterm> 
     2215 
     2216   <indexterm> 
     2217    <primary>table</primary> 
     2218    <secondary>partitioning</secondary> 
     2219   </indexterm> 
     2220 
     2221   <para> 
     2222    <productname>PostgreSQL</productname> supports basic table 
     2223    partitioning. This section describes why and how you can implement 
     2224    partitioning as part of your database design. 
     2225   </para> 
     2226 
     2227   <sect2 id="ddl-partitioning-overview"> 
     2228     <title>Overview</title> 
     2229 
     2230   <para> 
     2231    Partitioning refers to splitting what is logically one large table 
     2232    into smaller physical pieces. 
     2233    Partitioning can provide several benefits: 
     2234   <itemizedlist> 
     2235    <listitem> 
     2236     <para> 
     2237      Query performance can be improved dramatically for certain kinds 
     2238      of queries. 
     2239     </para> 
     2240    </listitem> 
     2241 
     2242    <listitem> 
     2243     <para> 
     2244      Update performance can be improved too, since each piece of the table 
     2245      has indexes smaller than an index on the entire data set would be. 
     2246      When an index no longer fits easily 
     2247      in memory, both read and write operations on the index take 
     2248      progressively more disk accesses. 
     2249     </para> 
     2250    </listitem> 
     2251 
     2252    <listitem> 
     2253     <para> 
     2254      Bulk deletes may be accomplished by simply removing one of the 
     2255      partitions, if that requirement is planned into the partitioning design. 
     2256      <command>DROP TABLE</> is far faster than a bulk <command>DELETE</>, 
     2257      to say nothing of the ensuing <command>VACUUM</> overhead. 
     2258     </para> 
     2259    </listitem> 
     2260 
     2261    <listitem> 
     2262     <para> 
     2263      Seldom-used data can be migrated to cheaper and slower storage media. 
     2264     </para> 
     2265    </listitem> 
     2266   </itemizedlist> 
     2267 
     2268    The benefits will normally be worthwhile only when a table would 
     2269    otherwise be very large. The exact point at which a table will 
     2270    benefit from partitioning depends on the application, although a 
     2271    rule of thumb is that the size of the table should exceed the physical 
     2272    memory of the database server. 
     2273   </para> 
     2274 
     2275   <para> 
     2276    Currently, <productname>PostgreSQL</productname> supports partitioning 
     2277    via table inheritance.  Each partition must be created as a child 
     2278    table of a single parent table.  The parent table itself is normally 
     2279    empty; it exists just to represent the entire data set.  You should be 
     2280    familiar with inheritance (see <xref linkend="ddl-inherit">) before 
     2281    attempting to implement partitioning. 
     2282   </para> 
     2283 
     2284   <para> 
     2285    The following forms of partitioning can be implemented in 
     2286    <productname>PostgreSQL</productname>: 
     2287 
     2288    <variablelist> 
     2289     <varlistentry> 
     2290      <term>Range Partitioning</term> 
     2291 
     2292      <listitem> 
     2293       <para> 
     2294        The table is partitioned into <quote>ranges</quote> defined 
     2295        by a key column or set of columns, with no overlap between 
     2296        the ranges of values assigned to different partitions.  For 
     2297        example one might partition by date ranges, or by ranges of 
     2298        identifiers for particular business objects. 
     2299       </para> 
     2300    &n