root/traduc/branches/bv747/manuel/ref/copy.sgml

<!--
$Header: /var/lib/cvs/pgsql-fr/sgml/ref/copy.sgml,v 1.8.2.3 2005/07/15 06:33:52 guillaume Exp $
PostgreSQL documentation
-->

<refentry id="SQL-COPY">
 <refmeta>
  <refentrytitle id="sql-copy-title">COPY</refentrytitle>
  <refmiscinfo>SQL - Instructions du langage</refmiscinfo>
 </refmeta>

 <refnamediv>
  <refname>COPY</refname>
  <refpurpose>copie des données entre un fichier et une table</refpurpose>
 </refnamediv>

 <indexterm zone="sql-copy">
  <primary>COPY</primary>
 </indexterm>

 <refsynopsisdiv>
<synopsis>
COPY <replaceable class="parameter">nomtable</replaceable> [ ( <replaceable
class="parameter">colonne</replaceable> [, ...] ) ]
    FROM { '<replaceable class="parameter">nomfichier</replaceable>' | STDIN }
    [ [ WITH ] 
          [ BINARY ] 
          [ OIDS ]
          [ DELIMITER [ AS ] '<replaceable
class="parameter">délimiteur</replaceable>' ]
          [ NULL [ AS ] '<replaceable class="parameter">chaîne
NULL</replaceable>' ] ]

COPY <replaceable class="parameter">nomtable</replaceable> [ ( <replaceable
class="parameter">colonne</replaceable> [, ...] ) ]
    TO { '<replaceable class="parameter">nomfichier</replaceable>' | STDOUT }
    [ [ WITH ] 
          [ BINARY ]
          [ OIDS ]
          [ DELIMITER [ AS ] '<replaceable
class="parameter">délimiteur</replaceable>' ]
          [ NULL [ AS ] '<replaceable class="parameter">chaîne
NULL</replaceable>' ] ]
</synopsis>
 </refsynopsisdiv>
 
 <refsect1>
  <title>Description</title>

  <para>
   <command>COPY</command> déplace des données entre les tables de
   <productname>PostgreSQL</productname> et les fichiers du système de
   fichiers standard. <command>COPY TO</command> copie le contenu d'une table
   <emphasis>dans</> un fichier alors que <command>COPY FROM</command> copie
   des données <emphasis>à partir</> d'un fichier dans une table (ajoutant les
   données à ce qui se trouve déjà dans la table).
  </para>

  <para>
   Si une liste de colonnes est spécifiée, <command>COPY</command> copiera
   seulement les données des colonnes spécifiées vers ou à partir du fichier.
   S'il y a des colonnes dans la table qui ne se trouvent pas dans la liste de
   colonnes, <command>COPY FROM</command> insérera les valeurs par défaut de ces
   colonnes.
  </para>

  <para>
   <command>COPY</command> avec un nom de fichier indique au serveur
   <productname>PostgreSQL</productname> de lire directement à partir d'un
   fichier ou d'écrire dans un fichier. Le fichier doit être accessible du
   serveur et le nom doit être spécifié à partir du point de vue du serveur.
   Lorsque <literal>STDIN</literal> ou <literal>STDOUT</literal> est indiqué,
   les données sont transmises via la connexion entre le client et le serveur.
  </para>
 </refsect1>

 <refsect1>
  <title>Paramètres</title>

  <variablelist>
   <varlistentry>
    <term><replaceable class="parameter">nomtable</replaceable></term>
    <listitem>
     <para>
     Le nom d'une table existante (pouvant être qualifié avec le nom du schéma).
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">colonne</replaceable></term>
     <listitem>
     <para>
      Une liste optionnelle de colonnes à copier. Si aucune liste n'est donnée,
      toutes les colonnes seront utilisées.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">nomfichier</replaceable></term>
    <listitem>
     <para>
      Le chemin absolu du fichier en entrée ou en sortie.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>STDIN</literal></term>
    <listitem>
     <para>
      Spécifie que l'entrée provient de l'application cliente.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>STDOUT</literal></term>
    <listitem>
     <para>
      Spécifie que la sortie va vers l'application cliente.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>BINARY</literal></term>
    <listitem>
     <para>
      Fait que toutes les données sont stockées ou lues au format binaire plutôt
      qu'en texte. Vous ne pouvez pas spécifier les options
      <option>DELIMITER</option> ou <option>NULL</option> en mode binaire.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>OIDS</literal></term>
    <listitem>
     <para>
      Demande la copie des OID pour chaque ligne. (Une erreur est levée si
      <literal>OIDS</literal> est spécifié pour une table qui ne possède pas
      d'OID.)
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">délimiteur</replaceable></term>
    <listitem>
     <para>
      Le caractère simple qui sépare les colonnes pour chaque ligne d'un
      fichier. La valeur par défaut est le caractère de tabulation.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">chaîne NULL</replaceable></term>
    <listitem>
     <para>
      La chaîne qui représente une valeur NULL. Par défaut, elle vaut
      <literal>\N</literal> (antislash-N). Vous pourriez préférer une chaîne
      vide par exemple.
     </para>

     <note>
      <para>
       Sur un <command>COPY FROM</command>, tout élément de données
       correspondant à cette chaîne sera stocké comme valeur NULL, donc vous
       devriez vous assurer que vous utilisez la même chaîne que celle que vous
       avez utilisé avec <command>COPY TO</command>.
      </para>
     </note>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

 <refsect1>
  <title>Notes</title>

   <para>
    <command>COPY</command> peut seulement être utilisé avec des tables réelles,
    pas avec des vues.
   </para>

   <para>
    Le mot clé <literal>BINARY</literal> fait que toutes les données sont
    stockées/lues dans le format binaire plutôt qu'en texte. Il est un peu
    plus rapide que le mode texte standard mais un fichier binaire est moins
    portable au travers des architectures machine et des versions de
    <productname>PostgreSQL</productname>.
   </para>

   <para>
    Vous devez avoir le droit SELECT sur la table dont les valeurs sont
    lues par <command>COPY TO</command> et le droit INSERT sur la table dont les
    valeurs sont insérées par <command>COPY FROM</command>.
   </para>

   <para>
    Les fichiers nommés dans une commande <command>COPY</command> sont lus ou
    écrits directement par le serveur, et non pas par l'application cliente. Du
    coup, ils doivent résider ou être accessible par la machine du serveur de
    bases de données. Ils doivent être accessibles et lisibles ou modifiables
    par l'utilisateur <productname>PostgreSQL</productname> (l'identifiant de
    l'utilisateur qui a exécuté le serveur), et non pas par le client.
    <command>COPY</command> nommant un fichier est seulement autorisé pour les
    superutilisateurs de la base de données car il autorise la lecture ou
    l'écriture de tout fichier auquel a accès le serveur.
   </para>

   <para>
    Ne confondez pas <command>COPY</command> avec l'instruction
    <command>\copy</command> de <application>psql</application>.
    <command>\copy</command> appelle <command>COPY FROM STDIN</command> ou
    <command>COPY TO STDOUT</command>, puis récupère/stocke la donnée dans un
    fichier accessible au client <application>psql</application>. Du coup,
    l'accès au fichier et les droits d'accès dépendent du client plutôt que du
    serveur quand <command>\copy</command> est utilisé.
   </para>

   <para>
    Il est recommandé que le nom du fichier utilisé dans
    <command>COPY</command> soit toujours utilisé avec un chemin absolu. Ceci
    est renforcé par le serveur dans le cas d'un <command>COPY TO</command>
    mais, pour les <command>COPY FROM</command>, vous devez avoir l'option de
    lire à partir d'un fichier spécifié par un chemin relatif. Le chemin sera
    interprété de façon relative au répertoire de travail du processus serveur
    (quelque part en-dessous du répertoire de données), pas dans le répertoire
    de travail du client.
   </para>

   <para>
    <command>COPY FROM</command> appellera tout déclencheur et vérifiera les
    contraintes sur la table de destination. Néanmoins, il n'appellera pas les
    règles.
   </para>

   <para>
    <command>COPY</command> stoppe l'opération à la première erreur. Ceci ne
    devrait apporter aucun problème dans le cas d'un <command>COPY TO</command>
    mais la table cible aura déjà reçu des lignes précédentes dans un
    <command>COPY FROM</command>. Ces lignes ne seront pas visibles ou
    accessibles mais elle occuperont toujours de l'espace disque. Ceci pourrait
    totaliser une perte considérable d'espace disque si l'échec arrivait lors
    d'une grande opération de copie. Vous pourriez souhaiter appeler
    <command>VACUUM</command> pour récupérer l'espace perdu.
   </para>
 </refsect1>

 <refsect1>
  <title>Formats de fichiers</title>

  <refsect2>
   <title>Format texte</title>

   <para>
    Quand <command>COPY</command> est utilisé sans l'option
    <literal>BINARY</literal>, les données lues ou écrites sont dans un fichier
    avec une ligne de données par ligne de la table. Les colonnes d'une ligne
    sont séparées par le caractère délimiteur. Les valeurs des colonnes sont des
    chaînes générées par la fonction de sortie ou acceptables par la fonction
    d'entrée de chaque type de données d'attribut. La chaîne NULL spécifiée est
    utilisée à la place des colonnes NULL. <command>COPY FROM</command> lèvera
    une erreur si une des lignes du fichier en entrée contient plus ou moins de
    colonnes qu'attendues. Si <literal>OIDS</literal> est spécifié, l'OID est lu
    ou écrit dans la première colonne, précédant ainsi les colonnes de données
    de l'utilisateur.
   </para>

   <para>
    La fin des données peut être représentée par une simple ligne contenant
    juste un antislash et un point (<literal>\.</>). Un marqueur de fin de
    données n'est pas nécessaire lors de la lecture d'un fichier car la fin du
    fichier sert bien&nbsp; il est seulement nécessaire lors de la copie de
    données vers ou à partir d'une application cliente en utilisant le protocole
    client pre-3.0.
   </para>

   <para>
    Les caractères antislash (<literal>\</>) pourraient être utilisés dans les
    données <command>COPY</command> pour mettre entre guillemets les données de
    caractères qui pourraient sinon être prises comme délimiteurs de ligne ou de
    colonne. En particulier, les caractères suivants <emphasis>doivent</> être
    précédés par un antislash s'ils apparaissent comme faisant partie de la
    valeur d'une colonne&nbsp;: antislash lui-même, nouvelle ligne, retour
    chariot et caractère délimiteur actuel.
   </para>

   <para>
    La chaîne NULL spécifiée est envoyée par <command>COPY TO</command> sans
    ajout d'antislash&nbsp;; au contraire, <command>COPY FROM</command> fait
    correspondre l'entrée avec la chaîne NULL avant de supprimer les antislash.
    Du coup, une chaîne NULL telle que <literal>\N</literal> ne peut pas être
    confondu avec la valeur de donnée réelle <literal>\N</literal> (qui serait
    représentée par <literal>\\N</literal>).
   </para>

   <para>
    Les séquences spéciales suivantes sont reconnues par <command>COPY
    FROM</command>&nbsp;:

   <informaltable>
    <tgroup cols="2">
     <thead>
      <row>
       <entry>Séquence</entry>
       <entry>Représenté</entry>
      </row>
     </thead>

     <tbody>
      <row>
       <entry><literal>\b</></entry>
       <entry>Suppression (ASCII 8)</entry>
      </row>
      <row>
       <entry><literal>\f</></entry>
       <entry>Retour chariot (ASCII 12)</entry>
      </row>
      <row>
       <entry><literal>\n</></entry>
       <entry>Nouvelle ligne (ASCII 10)</entry>
      </row>
      <row>
       <entry><literal>\r</></entry>
       <entry>Retour chariot (ASCII 13)</entry>
      </row>
      <row>
       <entry><literal>\t</></entry>
       <entry>Tabulation (ASCII 9)</entry>
      </row>
      <row>
       <entry><literal>\v</></entry>
       <entry>Tabulation verticale (ASCII 11)</entry>
      </row>
      <row>
       <entry><literal>\</><replaceable>chiffres</></entry>
       <entry>Un antislash suivi par un à trois chiffres en octal spécifie le
         caractère ayant ce code numérique</entry>
      </row>
     </tbody>
    </tgroup>
   </informaltable>

    Actuellement, <command>COPY TO</command> n'émettra jamais une séquence
    octale mais utilisera les autres séquences listées ci-dessus pour les
    caractères de contrôle.
   </para>

   <para>
    Tout autre caractère avec un antislash se représentera lui-même. 
    Néanmoins, attention à l'ajout non nécessaire d'antislash car cela
    pourrait produire accidentellement une correspondance de chaîne avec
    le marqueur de fin de données (<literal>\.</>) ou la chaîne NULL
    (<literal>\N</> par défaut). Ces chaînes seront reconnues avant tout
    traitement des antislashs.
   </para>

   <para>
    Il est fortement recommandé que les applications générant des données COPY
    convertissent les nouvelles lignes et retours chariot avec les séquences
    <literal>\n</> et <literal>\r</>, respectivement. À présent, il
    est possible de représenter un retour chariot par un antislash et un retour
    chariot, et de représenter une nouvelle ligne par un antislash et une
    nouvelle ligne. Néanmoins, ces représentations pourraient ne pas être
    acceptées dans les prochaines versions. Elles sont aussi hautement
    vulnérables à la corruption si le fichier COPY est transféré via différentes
    machines (par exemple, à partir d'un Unix vers un Windows ou vice versa).
   </para>

   <para>
    <command>COPY TO</command> terminera chaque ligne avec une
    nouvelle ligne style Unix (<quote><literal>\n</></>). Les serveurs
    fonctionnant avec MS Windows terminent la ligne avec un retour
    chariot/nouvelle ligne
    (<quote><literal>\r\n</></>) mais seulement pour <command>COPY</> dans un
    fichier serveur&nbsp;; pour des raisons de cohérence au niveau des
    plateformes, <command>COPY TO STDOUT</> envoie toujours
    <quote><literal>\n</></> quelque soit la plateforme du serveur.
    <command>COPY FROM</command> peut gérer des fin de lignes avec une nouvelle
    ligne, un retour chariot ou un retour chariot suivi d'une nouvelle ligne.
    Pour réduire les risques d'erreurs dûes à une nouvelle ligne ou un retour
    chariot sans antislash qui étaient des données, <command>COPY FROM</command>
    se plaindra si les fins de ligne dans l'entrée ne sont pas identiques.
   </para>
  </refsect2>

  <refsect2>
   <title>Format binaire</title>

   <para>
    Le format de fichier utilisé pour <command>COPY BINARY</command> a été
    modifié dans <productname>PostgreSQL</productname> 7.4. Le nouveau format
    consiste en un fichier d'en-tête, zéro ou plusieurs lignes contenant la
    donnée de la ligne et une queue de fichier. Les en-têtes et les données sont
    maintenant dans l'ordre d'octets du réseau.
   </para>

   <refsect3>
    <title>En-tête du fichier</title>

    <para>
     Le fichier d'en-tête consiste en 15 octets de champs fixes, suivis par une
     aire d'extension de l'en-tête de longueur variable. Les champs fixes
     sont&nbsp;:

    <variablelist>
     <varlistentry>
      <term>Signature</term>
      <listitem>
       <para>
        séquence de 11 octets <literal>PGCOPY\n\377\r\n\0</> --- notez que
        l'octet zéro est une partie requise de la signature. (La signature est
        conçue pour permettre une identification aisée des fichiers qui ont été
        déteriorés par un transfert qui ne s'est pas fait sur huit bits. Cette
        signature sera modifiée par des filtres de traduction de fin de ligne,
        suppression des octets zéro, suppression des bits de poids forts ou
        modification de parité.)
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>Champs de commutateurs</term>
      <listitem>
       <para>
        masque entier de 32 bits dénotant les aspects importants du format de
        fichier. Les bits sont numérotés de 0 (<acronym>LSB</>) à 31
        (<acronym>MSB</>). Notez que ce champ est stocké dans l'ordre des octets
        du réseau (l'octet le plus significatif en premier), comme le sont tous
        les champs d'entier utilisés dans le format de fichier. Les bits 16 à 31
        sont réservés pour dénoter les problèmes critiques de format de
        fichier&nbsp;; un lecteur devrait annuler l'opération s'il trouve un bit
        inattendu dans cet ensemble. Les bits 0 à 15 sont réservés pour signaler
        des problèmes de compatibilité de formats&nbsp;; un lecteur devrait
        simplement ignorer les bits inattendus dans cet ensemble. Actuellement,
        seul un bit est défini et le reste doit être à zéro&nbsp;:
        <variablelist>
         <varlistentry>
          <term>Bit 16</term>
          <listitem>
           <para>
            si 1, les OID sont inclus dans la donnée&nbsp;; si 0, non
           </para>
          </listitem>
         </varlistentry>
        </variablelist>
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>Longueur de l'aire d'extension de l'en-tête</term>
      <listitem>
       <para>
        Entier sur 32 bits, longueur en octets sur le reste de l'en-tête, ne
        s'incluant pas lui-même. Actuellement, c'est zéro et la première ligne
        suit immédiatement. Les modifications futures du format pourraient
        permettre la présence de données supplémentaires dans l'en-tête. Un
        lecteur devrait passer silencieusement toute donnée dans l'extension de
        l'en-tête s'il ne sait pas quoi faire avec.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
    </para>

    <para>
     L'aire d'extension de l'en-tête devrait contenir une séquence de morceaux
     qui s'identifient eux-même. Le champ des commutateurs n'a pas pour but
     d'indiquer aux lecteurs ce qui se trouve dans l'aire d'extension. La
     conception spécifique du contenu de l'extension de l'en-tête est laissée à
     une prochaine version.
    </para>

    <para>
     Cette conception permet des ajouts d'en-têtes compatibles (ajout de
     morceaux d'extension d'en-tête, ou initialisation des options de faible
     poids) et modifications non compatibles (initialisation des options de
     poids pour signaler des modifications, et ajout des données de support dans
     l'aire d'extension si nécessaire).
    </para>
   </refsect3>

   <refsect3>
    <title>Lignes</title>
    <para>
     Chaque ligne commence avec un compteur sur 16 bits du nombre de champs dans
     la ligne. (Actuellement, toutes les lignes dans une table auront le même
     compte mais ceci pourrait ne pas être toujours vrai.) Ensuite, répété pour
     chaque champ de la ligne, il y a un mot de 32 bits suivi par autant
     d'octets que de données. (Le mot clé n'inclut pas sa propre longueur et
     peut donc valoir zéro.) Comme cas spécial, -1 indique une valeur de champ
     NULL. Aucun octet de valeur ne suit dans le cas NULL.
    </para>

    <para>
     Il n'y a pas d'ajout pour l'alignement ou toute autre donnée supplémentaire
     entre les champs.
    </para>

    <para>
     Actuellement, toutes les valeurs dans un fichier <command>COPY
     BINARY</command> sont supposées être dans un format binaire (format code
     un). Une future extension pourrait ajouter un champ d'en-tête qui autorise
     la spécification des codes de format par colonne.
    </para>

    <para>
     Pour déterminer le format binaire approprié pour la donnée réelle, vous
     devriez consulter le source de <productname>PostgreSQL</productname>, en
     particulier les fonctions <function>*send</> et <function>*recv</> pour
     chaque type de données de la colonne (typiquement ces fonctions se
     trouvent dans le répertoire <filename>src/backend/utils/adt/</filename> des
     sources).
    </para>

    <para>
     Si les OID sont inclus dans le fichier, le champ OID est immédiatement
     suivi du compteur de champ. C'est un champ normal sauf qu'il n'est pas
     inclus dans le champ compteur. En particulier, il a une longueur d'un mot
     --- ceci permettra la gestion d'OID à quatre octets plutôt que huit sans
     trop de peine et permettra l'affichage des OID comme NULL si cela se révèle
     intéressant.
    </para>
   </refsect3>

   <refsect3>
    <title>Queue du fichier</title>

    <para>
     La fin du fichier consiste en un entier sur 16 bits contenant -1. Ceci est
     facilement distingué du compteur de champ d'une ligne.
    </para>

    <para>
     Un lecteur devrait rapporter une erreur si un mot de comptage de champ est
     soit -1 soit le nombre attendu de colonnes. Ceci fournit une vérification
     supplémentaire sur quelque chose pouvant être hors synchronisation avec les
     données.
    </para>
   </refsect3>
  </refsect2>
 </refsect1>

 <refsect1>
  <title>Exemples</title>

  <para>
   L'exemple suivant copie une table vers le client en utilisant la barre
   verticale (<literal>|</literal>) comme délimiteur de champ&nbsp;:
<programlisting>
COPY pays TO STDOUT WITH DELIMITER '|';
</programlisting>
  </para>

  <para>
   Pour copier des données de la table <literal>pays</> vers un fichier&nbsp;:
<programlisting>
COPY pays FROM '/usr1/proj/bray/sql/pays_donnees';
</programlisting>
  </para>

  <para>
   Voici un exemple de données convenable pour une table provenant de
   <literal>STDIN</literal>&nbsp;:
<programlisting>
AF      AFGHANISTAN
AL      ALBANIA
DZ      ALGERIA
ZM      ZAMBIA
ZW      ZIMBABWE
</programlisting>
   Notez que l'espace blanc sur chaque ligne est en fait un caractère de
   tabulation.
  </para>

  <para>
   Ce qui suit représente les même données, au format binaire. La donnée est
   affichée après filtrage à travers l'outil Unix <command>od -c</command>. La
   table a trois colonnes&nbsp;; la première est de type <type>integer</type>.
   Toutes les lignes ont une valeur NULL sur la troisième colonne.
<programlisting>
0000000   P   G   C   O   P   Y  \n 377  \r  \n  \0  \0  \0  \0  \0  \0
0000020  \0  \0  \0  \0 003  \0  \0  \0 002   A   F  \0  \0  \0 013   A
0000040   F   G   H   A   N   I   S   T   A   N 377 377 377 377  \0 003
0000060  \0  \0  \0 002   A   L  \0  \0  \0 007   A   L   B   A   N   I
0000100   A 377 377 377 377  \0 003  \0  \0  \0 002   D   Z  \0  \0  \0
0000120 007   A   L   G   E   R   I   A 377 377 377 377  \0 003  \0  \0
0000140  \0 002   Z   M  \0  \0  \0 006   Z   A   M   B   I   A 377 377
0000160 377 377  \0 003  \0  \0  \0 002   Z   W  \0  \0  \0  \b   Z   I
0000200   M   B   A   B   W   E 377 377 377 377 377 377
</programlisting>
  </para>
 </refsect1>

 <refsect1>
  <title>Compatibilité</title>

  <para>
   Il n'existe pas d'instruction <command>COPY</command> dans le standard SQL.
  </para>

  <para>
   La syntaxe suivante était utilisée avant PostgreSQL version 7.3 et est
   toujours supportée&nbsp;:

<synopsis>
COPY [ BINARY ] <replaceable class="parameter">nomtable</replaceable> [ WITH OIDS ]
    FROM { '<replaceable class="parameter">nomfichier</replaceable>' | STDIN }
    [ [USING] DELIMITERS '<replaceable class="parameter">délimiteur</replaceable>' ]
    [ WITH NULL AS '<replaceable class="parameter">chaîne NULL</replaceable>' ]

COPY [ BINARY ] <replaceable class="parameter">nomtable</replaceable> [ WITH OIDS ]
    TO { '<replaceable class="parameter">nomfichier</replaceable>' | STDOUT }
    [ [USING] DELIMITERS '<replaceable class="parameter">délimiteur</replaceable>' ]
    [ WITH NULL AS '<replaceable class="parameter">chaîne NULL</replaceable>' ]
</synopsis>
  </para>
 </refsect1>
</refentry>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"../reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:"/usr/lib/sgml/catalog"
sgml-local-ecat-files:nil
End:
-->