root/traduc/branches/bv747/manuel/extend.sgml

<!--
$Header: /cvsroot/pgsql-fr/sgml/extend.sgml,v 1.1 2003/08/15 13:41:51 guillaume 
Exp $-->

 <chapter id="extend">
  <title>Extension de <acronym>SQL</acronym></title>

   <indexterm zone="extend">
    <primary>Extension de SQL</primary>
   </indexterm>

  <para>
  Dans cette section, nous discutons de la façon d'étendre le langage de
  requêtes <productname>PostgreSQL</productname> en ajoutant des&nbsp;:
  <itemizedlist spacing="compact" mark="bullet">
    <listitem>
     <para>
      fonctions (commençant à la <xref linkend="xfunc">)&nbsp;;
     </para>
    </listitem>
    <listitem>
     <para>
      agrégats (commençant à la <xref linkend="xaggr">)&nbsp;;
     </para>
    </listitem>
    <listitem>
     <para>
      types de données (commençant à la <xref linkend="xtypes">)&nbsp;;
     </para>
    </listitem>
    <listitem>
     <para>
      opérateurs (commençant à la <xref linkend="xoper">)&nbsp;;
     </para>
    </listitem>
    <listitem>
     <para>
     classes d'opérateurs pour les index (commençant à la
     <xref linkend="xindex">).
     </para>
    </listitem>
   </itemizedlist>
  </para>

  <sect1 id="extend-how">
   <title>Comment fonctionne l'extensibilité</title>

   <para>
    <productname>PostgreSQL</productname> est extensible parce qu'il opère
    grâce à un catalogue. Si vous êtes familier avec les systèmes standards de
    bases de données, vous savez qu'ils enregistrent les informations
    concernant les bases de données, les tables, les colonnes, etc., dans ce
    qu'on nomme communément des catalogues systèmes (certains systèmes appellent
    cela le dictionnaire de données). Pour l'utilisateur, les catalogues
    apparaissent comme des tables ordinaires mais le <acronym>SGBD</acronym>
    y enregistre ses écritures internes. Une différence essentielle entre
    <productname>PostgreSQL</productname> et les systèmes de bases de données
    relationnelles est que <productname>PostgreSQL</productname> enregistre
    beaucoup plus d'informations dans ses catalogues&nbsp;: pas seulement 
    l'information à propos des tables et des colonnes, mais aussi
    l'information au sujet des types de données, des fonctions, des méthodes
    d'accès, etc. Ces tables peuvent être modifiées par l'utilisateur et,
    puisque <productname>PostgreSQL</productname> fonde ses opérations sur ces
    tables, cela signifie que <productname>PostgreSQL</productname> peut être
    étendu par les utilisateurs. En comparaison, les systèmes de bases de 
    données conventionnels peuvent seulement être étendus en modifiant les
    procédures dans le code source ou en installant des modules spécifiquement
    écrits par le vendeur de <acronym>SGBD</acronym>.
  </para>
  
  <para>Encore mieux, le serveur <productname>PostgreSQL</productname> peut
    s'ajouter du code écrit par l'utilisateur grâce au chargement
    dynamique. C'est-à-dire que l'utilisateur peut spécifier un fichier de code
    objet (par exemple une bibliothèque partagée) qui implémente un nouveau
    type ou une nouvelle fonction et que <productname>PostgreSQL</productname>
    chargera à la demande. Il est encore plus évident d'ajouter au serveur du
    code écrit en <acronym>SQL</acronym>. Cette possibilité de modifier son
    fonctionnement <quote>à la volée</quote> fait de
    <productname>PostgreSQL</productname> un outil unique pour le prototypage
    rapide de nouvelles applications et de structures de stockage.
  </para>
  
 </sect1>
   
   <sect1 id="extend-type-system"> 
     <title>Système de typage de <productname>PostgreSQL</productname></title>

   <indexterm zone="extend-type-system">
    <primary>type de base</primary>
   </indexterm>

   <indexterm zone="extend-type-system">
    <primary>type de données</primary>
    <secondary>base</secondary>
   </indexterm>

   <indexterm zone="extend-type-system">
    <primary>type composé</primary>
   </indexterm>

   <indexterm zone="extend-type-system">
    <primary>type de données</primary>
    <secondary>composé</secondary>
   </indexterm>

   <para>
    Les types de données de <productname>PostgreSQL</productname> sont répartis en types de base, 
    types composé, types de domaine et pseudo-types.
   </para>

   <para>
    Les types de base sont ceux qui, comme <type>int4</type>, sont implémentés
    sous le niveau du langage <acronym>SQL</acronym> (typiquement dans un
    langage de bas niveau comme le C). Ils correspondent généralement à ce qui 
    est souvent connu comme des types de données abstraits.  
    <productname>PostgreSQL</productname> peut  opérer sur de tels types
    seulement au moyen de fonctions fournies par l'utilisateur et n'en comprend
    le fonctionnement que dans la mesure où l'utilisateur les décrit. Les types
    de base sont divisés en types scalaires et types tableaux. Pour chaque type
    scalaire, un type tableau  est automatiquement créé. Ce type tableau peut
    contenir des tableaux à taille variable du type scalaire correspondant.
   </para>

   <para>
    Les types composés, ou types lignes, sont créés chaque fois qu'un
    utilisateur crée une table&nbsp;; il est aussi possible de définir un type
    composé autonome sans table associée. Un type composé est simplement
    une liste de types de base avec des noms de champs associés. Une valeur pour
    un type composé correspond à une ligne ou un enregistrement de valeurs de
    champ. L'utilisateur peut accéder à ces champs à partir de requêtes
    <acronym>SQL</>.
   </para>

   <para>
    Un type de domaine est basé sur un type de base particulier et il est
    interchangeable à de multiples fins avec son type de base. Toutefois, un
    domaine peut avoir des contraintes qui restreignent ses valeurs valides à un
    sous-ensemble de ce qui est permis par le type de base sous-jacent. Les
    domaines peuvent être créés par de simples commandes <acronym>SQL</>.
   </para>

   <para>   
    Enfin, il existe quelques <quote>pseudo-types</> pour des besoins
    particuliers. Les pseudo-types ne peuvent pas apparaître comme des champs de
    table ou des types composés, mais ils peuvent être utilisés pour déclarer
    les types des arguments et des résultats de fonctions. Dans le système de
    typage, ils fournissent un mécanisme pour identifier des classes spéciales de
    fonctions. La <xref linkend="datatype-pseudotypes-table"> donne la liste des
    pseudo-types existants.   
   </para>

   <sect2 id="types-polymorphic">
    <title>Types et fonctions polymorphes</title>

   <indexterm>
    <primary>types polymorphes</primary>
   </indexterm>

   <indexterm>
    <primary>fonctions polymorphes</primary>
   </indexterm>

   <para>
    Deux pseudo-types particulièrement intéressants sont <type>anyelement</> et
    <type>anyarray</>, collectivement appelés <firstterm>types polymorphes</>.
    Toute fonction déclarée utilisant ces types est dite <firstterm>fonction
    polymorphe</>. Une fonction polymorphe peut opérer sur de nombreux et
    différents types de données, les types de données spécifiques étant
    déterminés par les types des données réellement passés lors d'un appel
    particulier de la fonction.
   </para>

   <para>
    Les arguments et les résultats polymorphes sont liés les uns aux autres et
    sont résolus dans un type de données spécifique quand une requête faisant
    appel à une fonction polymorphe est analysée. Chaque occurrence déclarée 
    comme <type>anyelement</type> (soit argument, soit valeur renvoyée par la
    fonction) peut prendre n'importe quel type réel de données mais, lors d'un
    appel de fonction donné, elles doivent toutes avoir le
    <emphasis>même</emphasis> type réel. Chaque occurrence déclarée comme
    <type>anyarray</type> peut prendre n'importe quel type de données tableau
    mais, de la même façon, elles doivent toutes être du
    <emphasis>même</emphasis> type. Si des occurrences sont déclarées comme
    <type>anyarray</type> et d'autres comme <type>anyelement</type>, le type
    de tableau réel des occurrences <type>anyarray</type> doit être un tableau
    dont les éléments sont du même type que ceux apparaissant dans les
    occurrences de type <type>anyelement</type>.
   </para>

   <para>
    Ainsi, quand plus d'une occurrence d'argument est déclarée avec un type
    polymorphe, l'effet direct est que seulement certaines combinaisons de
    types réels d'argument sont autorisées. Par exemple, une fonction déclarée
    comme <literal>foo(anyelement, anyelement)</> prendra en argument
    n'importe quelles valeurs en argument à condition qu'elles soient du même
    type de données.
   </para>

   <para>
    Quand la valeur renvoyée par une fonction est déclarée de type polymorphe,
    il doit exister au moins une occurrence d'argument également polymorphe, et
    le type réel de donnée passé comme argument détermine le type réel de
    résultat renvoyé lors de  cet appel à la fonction. Par exemple, s'il
    n'existait pas déjà un mécanisme d'extraction d'éléments (indexation) de
    tableau, on pourrait définir une fonction qui implémente ce mécanisme comme
    ceci&nbsp;: <literal>indice(anyarray, integer) returns anyelement</>. La
    déclaration de fonction contraint le premier argument réel à être de type
    tableau et permet à l'analyseur d'inférer le type correct de résultat à
    partir du type réel du premier argument.
   </para>
  </sect2>

   <sect2>
    <title>Types de base</title>

    <para>
     Les types de base sont ceux implémentés avant le langage 
     <acronym>SQL</> comme <type>int4</type> (typiquement dans un langage de
     bas niveau comme le C). Ils correspondent généralement à ce qu'on nomme
     les types de données abstraits. <productname>PostgreSQL</productname> peut
     opérer avec de tels types seulement au travers de fonctions apportées par
     l'utilisateur et comprend uniquement le comportement de tels types par la
     description qu'en a fait l'utilisateur. Les types de base sont ensuite
     sous-divisés en types scalaires et tableaux. Pour chaque type scalaire, un
     type de tableau correspondant est automatiquement créé, pouvant contenir
     des tableaux à la taille des variables de ce type scalaire.
    </para>
    
   </sect2>

   <sect2>
    <title>Types composites</title>

    <para>
     Les types composites, ou types lignes, sont crées lorsqu'un utilisateur
     crée une table&nbsp;; il est aussi possible de définir un type composite se
     suffisant à lui-même (<quote>stand-alone</>) sans table associée. Un type
     composite est simplement une liste de types de base avec les noms des
     champs associés. Une valeur d'un type composite est une ligne ou un
     enregistrement de champs. L'utilisateur peut accéder aux champs du
     composant à partir de requêtes <acronym>SQL</>.
    </para>
    
   </sect2>

   <sect2>
    <title>Domaines</title>

    <para>
     Un domaine est basé sur un type de base particulier et est interchangeable
     pour de nombreux buts avec son type de base. Néanmoins, un domaine pourrait
     avoir des contraintes restreignant ses valeurs valides à un sous-ensemble
     du type de base de départ.
    </para>

    <para>
     Les domaines peuvent être créés avec les commandes <acronym>SQL</>
     <command>CREATE DOMAIN</command>. Leur création et utilisation ne sont pas
     discutées dans ce chapitre.
    </para>
   </sect2>

   <sect2>
    <title>Pseudo-Types</title>

    <para>
     Il existe quelques <quote>pseudo-types</> pour certains buts très
     spécifiques. Les pseudo-types ne peuvent pas apparaître comme colonnes de
     tables ou d'attributs de types composés, mais peuvent être utilisés pour
     déclarer les types d'argument ou de résultat de fonctions. Cela fournit un
     mécanisme à l'intérieur du système de types pour identifier les classes
     spéciales de fonctions. Le <xref linkend="datatype-pseudotypes-table"> liste
     les pseudos-types existants.
    </para>
    
   </sect2>

   <sect2 id="extend-types-polymorphic">
    <title>Types polymorphiques</title>

   <indexterm zone="extend-types-polymorphic">
    <primary>type polymorphique</primary>
   </indexterm>

   <indexterm zone="extend-types-polymorphic">
    <primary>fonction polymorphique</primary>
   </indexterm>

   <indexterm zone="extend-types-polymorphic">
    <primary>type</primary>
    <secondary>polymorphique</secondary>
   </indexterm>

   <indexterm zone="extend-types-polymorphic">
    <primary>fonction</primary>
    <secondary>polymorphique</secondary>
   </indexterm>

    <para>
     Deux pseudo-types d'un grand intérêt sont <type>anyelement</> et
     <type>anyarray</>, collectivement appelés des <firstterm>types
     polymorphiques</>. Toute fonction déclarée utilisant ces types est dite
     être une <firstterm>fonction polymorphique</>. Une fonction polymorphique
     peut opérer sur différents types de données, les types de données
     spécifiques étant déterminés par les types de données réellement passés
     lors d'un appel particulier.
    </para>

    <para>
     Les arguments et résultats polymorphiques sont liés les uns aux autres et
     sont modifiés en un type spécifique de données lorsqu'une requête appelant
     une fonction polymorphique est analysée. Chaque position (argument ou
     valeur de retour) déclarée en tant que <type>anyelement</type> est
     autorisée à avoir tout type de donnée spécifique mais, sur un seul appel,
     elles doivent toutes avoir le <emphasis>même</emphasis> type. Chaque
     position déclarée comme <type>anyarray</type> peut avoir n'importe quel
     type de données mais, de façon similaire, elles doivent toutes avoir le même
     type. Si des positions sont déclarées <type>anyarray</type> et d'autres
     <type>anyelement</type>, le type de tableau réel dans les positions
     <type>anyarray</type> doit être un tableau dont les éléments sont du même
     type que ceux des positions <type>anyelement</type>.
    </para>

    <para>
     Du coup, lorsque plus d'un argument est déclaré polymorphique, l'effet est
     que seules certaines combinaisons de types d'argument sont autorisées. Par
     exemple, une fonction déclarée de cette façon
     <literal>foo(anyelement, anyelement)</> prendra seulement deux valeurs en
     entrées, à condition qu'elles soient du même type.
    </para>

    <para>
     Lorsque la valeur de retour d'une fonction est déclarée polymorphique, il
     doit exister au moins un argument lui-aussi polymorphique et le type de
     données fourni en argument détermine le type de données du code de retour
     pour cet appel. Par exemple, s'il n'existait pas déjà un mécanisme
     d'abonnement d'un tableau, nous pourrions définir une fonction qui
     implémente cet abonnement avec <literal>subscript(anyarray, integer)
     returns anyelement</>. Cette déclaration contraint le premier argument à
     être de type tableau et permet à l'analyseur d'inférer le bon type de
     retour à partir du type du premier argument.
    </para>
   </sect2>
  </sect1>

  &xfunc;
  &xaggr;
  &xtypes;
  &xoper;
  &xindex;

<!-- 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:
-->