datatype.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->

 <chapter id="datatype">
  <title id="datatype-title">Types de données</title>

  <indexterm zone="datatype">
   <primary>Types de données</primary>
  </indexterm>

  <indexterm>
   <primary>type</primary>
   <see>type de données</see>
  </indexterm>

  <para>
   <productname>PostgreSQL</productname> offre un large choix de types de 
   données disponibles nativement.
   Les utilisateurs peuvent ajouter de nouveaux types à 
   <productname>PostgreSQL</productname> en utilisant la commande <xref
   linkend="sql-createtype" endterm="sql-createtype-title"/>.
  </para>

  <para>
   Le <xref linkend="datatype-table"/> montre tous les types de données
   généraux disponibles nativement.
   La plupart des types de données alternatifs listés dans la colonne
   <quote>Alias</quote> sont les noms utilisés en interne par
   <productname>PostgreSQL</productname> pour des raisons historiques.
   Il existe également d'autres types de données internes ou obsolètes,
   mais ils ne sont pas listés ici.
 
  </para>

   <table id="datatype-table">
    <title>Types de données</title>
    <tgroup cols="3">
     <colspec colnum="1" colwidth="2*"/>
     <colspec colnum="2" colwidth="1*"/>
     <colspec colnum="3" colwidth="3*"/>
     <thead>
      <row>
       <entry>Nom</entry>
       <entry>Alias</entry>
       <entry>Description</entry>
      </row>
     </thead>

     <tbody>
      <row>
       <entry><type>bigint</type></entry>
       <entry><type>int8</type></entry>
       <entry>Entier signé sur 8 octets</entry>
      </row>

      <row>
       <entry><type>bigserial</type></entry>
       <entry><type>serial8</type></entry>
       <entry>Entier sur 8 octets à incrémentation automatique</entry>
      </row>

      <row>
       <entry><type>bit [ (<replaceable>n</replaceable>) ]</type></entry>
       <entry></entry>
       <entry>Suite de bits de longueur fixe</entry>
      </row>

      <row>
       <entry><type>bit varying [ (<replaceable>n</replaceable>) ]</type></entry>
       <entry><type>varbit</type></entry>
       <entry>Suite de bits de longueur variable</entry>
      </row>

      <row>
       <entry><type>boolean</type></entry>
       <entry><type>bool</type></entry>
       <entry>Booléen (Vrai/Faux)</entry>
      </row>

      <row>
       <entry><type>box</type></entry>
       <entry></entry>
       <entry>Boîte rectangulaire dans le plan</entry>
      </row>

      <row>
       <entry><type>bytea</type></entry>
       <entry></entry>
       <entry>Donnée binaire (<quote>tableau d'octets</quote>)</entry>
      </row>

      <row>
       <entry><type>character varying [ (<replaceable>n</replaceable>) ]</type></entry>
       <entry><type>varchar [ (<replaceable>n</replaceable>) ]</type></entry>
       <entry>Chaîne de caractères de longueur variable</entry>
      </row>

      <row>
       <entry><type>character [ (<replaceable>n</replaceable>) ]</type></entry>
       <entry><type>char [ (<replaceable>n</replaceable>) ]</type></entry>
       <entry>Chaîne de caractères de longueur fixe</entry>
      </row>

      <row>
       <entry><type>cidr</type></entry>
       <entry></entry>
       <entry>Adresse réseau IPv4 ou IPv6 </entry>
      </row>

      <row>
       <entry><type>circle</type></entry>
       <entry></entry>
       <entry>Cercle dans le plan</entry>
      </row>

      <row>
       <entry><type>date</type></entry>
       <entry></entry>
       <entry>Date du calendrier (année, mois, jour)</entry>
      </row>

      <row>
       <entry><type>double precision</type></entry>
       <entry><type>float8</type></entry>
       <entry>Nombre à virgule flottante de double précision</entry>
      </row>

      <row>
       <entry><type>inet</type></entry>
       <entry></entry>
       <entry>Adresse d'ordinateur IPv4 ou IPv6</entry>
      </row>

      <row>
       <entry><type>integer</type></entry>
       <entry><type>int</type>, <type>int4</type></entry>
       <entry>Entier signé sur 4 octets</entry>
      </row>

      <row>
       <entry><type>interval [ (<replaceable>p</replaceable>) ]</type></entry>
       <entry></entry>
       <entry>Intervalle de temps</entry>
      </row>

      <row>
       <entry><type>line</type></entry>
       <entry></entry>
       <entry>Droite (infinie) dans le plan</entry>
      </row>

      <row>
       <entry><type>lseg</type></entry>
       <entry></entry>
       <entry>Segment de droite dans le plan</entry>
      </row>

      <row>
       <entry><type>macaddr</type></entry>
       <entry></entry>
       <entry>Adresse MAC</entry>
      </row>

      <row>
       <entry><type>money</type></entry>
       <entry></entry>
       <entry>Montant monétaire</entry>
      </row>

      <row>
       <entry><type>numeric [ (<replaceable>p</replaceable>,
         <replaceable>s</replaceable>) ]</type></entry>
       <entry><type>decimal [ (<replaceable>p</replaceable>,
         <replaceable>s</replaceable>) ]</type></entry>
       <entry>Nombre exact dont la précision peut être précisée</entry>
      </row>

      <row>
       <entry><type>path</type></entry>
       <entry></entry>
       <entry>Chemin géométrique dans le plan</entry>
      </row>

      <row>
       <entry><type>point</type></entry>
       <entry></entry>
       <entry>Point géométrique dans le plan</entry>
      </row>

      <row>
       <entry><type>polygon</type></entry>
       <entry></entry>
       <entry>Chemin géométrique fermé dans le plan</entry>
      </row>

      <row>
       <entry><type>real</type></entry>
       <entry><type>float4</type></entry>
       <entry>Nombre à virgule flottante de simple précision</entry>
      </row>

      <row>
       <entry><type>smallint</type></entry>
       <entry><type>int2</type></entry>
       <entry>Entier signé sur 2 octets</entry>
      </row>

      <row>
       <entry><type>serial</type></entry>
       <entry><type>serial4</type></entry>
       <entry>Entier sur 4 octets à incrémentation automatique</entry>
      </row>

      <row>
       <entry><type>text</type></entry>
       <entry></entry>
       <entry>Chaîne de caractères de longueur variable</entry>
      </row>

      <row>
       <entry><type>time [ (<replaceable>p</replaceable>) ] [ without time zone ]</type></entry>
       <entry></entry>
       <entry>Heure du jour</entry>
      </row>

      <row>
       <entry><type>time [ (<replaceable>p</replaceable>) ] with time zone</type></entry>
       <entry><type>timetz</type></entry>
       <entry>Heure du jour, avec fuseau horaire</entry>
      </row>

      <row>
       <entry><type>timestamp [ (<replaceable>p</replaceable>) ] [ without time zone ]</type></entry>
       <entry></entry>
       <entry>Date et heure</entry>
      </row>

      <row>
       <entry><type>timestamp [ (<replaceable>p</replaceable>) with time zone</type></entry>
       <entry><type>timestamptz</type></entry>
       <entry>Date et heure, avec fuseau horaire</entry>
      </row>

      <row>
       <entry><type>tsquery</type></entry>
       <entry></entry>
       <entry>requête pour la recherche plein texte</entry>
      </row>

      <row>
       <entry><type>tsvector</type></entry>
       <entry></entry>
       <entry>document pour la recherche plein texte</entry>
      </row>

      <row>
       <entry><type>txid_snapshot</type></entry>
       <entry></entry>
       <entry>image de l'identifiant de transaction au niveau utilisateur</entry>
      </row>

      <row>
       <entry><type>uuid</type></entry>
       <entry></entry>
       <entry>identifiant unique universel</entry>
      </row>

      <row>
       <entry><type>xml</type></entry>
       <entry></entry>
       <entry>données XML</entry>
      </row>
     </tbody>
    </tgroup>
   </table>

  <note>
   <title>Compatibilité</title>
   <para>
    Les types suivants sont conformes à la norme <acronym>SQL</acronym>:
    <type>bigint</type>, <type>bit</type>, <type>bit varying</type>, <type>boolean</type>, 
    <type>char</type>,
    <type>character varying</type>, <type>character</type>,
    <type>varchar</type>, <type>date</type>, 
    <type>double precision</type>, <type>integer</type>, <type>interval</type>,
    <type>numeric</type>, <type>decimal</type>, <type>real</type>,
    <type>smallint</type>, <type>time</type> (avec et sans fuseau horaire),
	<type>timestamp</type> (avec et sans fuseau horaire), <type>xml</type>, .
   </para>
  </note>

<!-- invertible = inversable ? -->
  <para>
   Chaque type de données a une représentation externe déterminée par
   ses fonctions d'entrée et de sortie. De nombreux types de données
   internes ont un format externe évident. Cependant, certains types
   sont spécifiques à <productname>PostgreSQL</productname>,
   comme les chemins géométriques, ou acceptent différents formats,
   comme les types de données de date et d'heure.
   Certaines fonctions d'entrée et de sortie ne sont pas inversables&nbsp;:
   le résultat de la fonction de sortie peut manquer de précision
   comparé à l'entrée initiale.
  </para>

  <sect1 id="datatype-numeric">
   <title>Types numériques</title>

   <indexterm zone="datatype-numeric">
    <primary>Type de données</primary>
    <secondary>numeric</secondary>
   </indexterm>

   <para>
    Les types numériques sont constitués d'entiers de 2, 4 ou 8 octets,
    de nombres à virgule flottante de 4 ou 8 octets et de décimaux dont
    la précision peut être indiquée. Le <xref linkend="datatype-numeric-table"/>
    précise les types disponibles.
   </para>

    <table id="datatype-numeric-table">
     <title>Types numériques</title>
     <tgroup cols="4">
     <colspec colnum="1" colwidth="0.7*"/>
     <colspec colnum="2" colwidth="0.7*"/>
     <colspec colnum="3" colwidth="1.3*"/>
     <colspec colnum="4" colwidth="1.3*"/>
      <thead>
       <row>
        <entry>Nom</entry>
        <entry>Taille de stockage</entry>
        <entry>Description</entry>
        <entry>Étendue</entry>
       </row>
      </thead>

      <tbody>
       <row>
        <entry><type>smallint</type></entry>
        <entry>2 octets</entry>
        <entry>entier de faible étendue</entry>
        <entry>de -32768 à +32767</entry>
       </row>
       <row>
       <entry><type>integer</type></entry>
        <entry>4 octets</entry>
        <entry>entier habituel</entry>
        <entry>de -2147483648 à +2147483647</entry>
       </row>
       <row>
        <entry><type>bigint</type></entry>
        <entry>8 octets</entry>
        <entry>grand entier</entry>
        <entry>de -9223372036854775808 à 9223372036854775807</entry>
       </row>

       <row>
        <entry><type>decimal</type></entry>
        <entry>variable</entry>
        <entry>précision indiquée par l'utilisateur, valeur exacte</entry>
        <entry>pas de limite</entry>
       </row>
       <row>
        <entry><type>numeric</type></entry>
        <entry>variable</entry>
        <entry>précision indiquée par l'utilisateur, valeur exacte</entry>
        <entry>pas de limite</entry>
       </row>

       <row>
        <entry><type>real</type></entry>
        <entry>4 octets</entry>
        <entry>précision variable, valeur inexacte</entry>
        <entry>précision de 6 décimales</entry>
       </row>
       <row>
        <entry><type>double precision</type></entry>
        <entry>8 octets</entry>
        <entry>précision variable, valeur inexacte</entry>
        <entry>précision de 15 décimales</entry>
       </row>

       <row>
        <entry><type>serial</type></entry>
        <entry>4 octets</entry>
        <entry>entier à incrémentation automatique</entry>
        <entry>de 1 à 2147483647</entry>
       </row>

       <row>
        <entry><type>bigserial</type></entry>
        <entry>8 octets</entry>
        <entry>entier de grande taille à incrémentation automatique</entry>
        <entry>de 1 à 9223372036854775807</entry>
       </row>
      </tbody>
     </tgroup>
    </table>

   <para>
    La syntaxe des constantes pour les types numériques est décrite
    dans la <xref linkend="sql-syntax-constants"/>. Les types numériques
    ont un ensemble complet d'opérateurs arithmétiques et de fonctions.
    On peut se référer au <xref linkend="functions"/> pour plus d'informations.
    Les sections suivantes décrivent ces types en détail.
   </para>

   <sect2 id="datatype-int">
    <title>Types entiers</title>

    <indexterm zone="datatype-int">
     <primary>integer</primary>
    </indexterm>

    <indexterm zone="datatype-int">
     <primary>smallint</primary>
    </indexterm>

    <indexterm zone="datatype-int">
     <primary>bigint</primary>
    </indexterm>

    <indexterm>
     <primary>int4</primary>
     <see>integer</see>
    </indexterm>

    <indexterm>
     <primary>int2</primary>
     <see>smallint</see>
    </indexterm>

    <indexterm>
     <primary>int8</primary>
     <see>bigint</see>
    </indexterm>

    <para>
     Les types <type>smallint</type>, <type>integer</type> et
     <type>bigint</type> stockent des nombres entiers, c'est-à-dire
     sans décimale, de différentes étendues.
     Toute tentative d'y stocker une valeur en dehors de l'échelle
     produit une erreur.
    </para>

    <para>
     Le type <type>integer</type> est le plus courant. Il offre un
     bon compromis entre capacité, espace utilisé et performance.
     Le type <type>smallint</type> n'est utilisé que si l'économie
     d'espace disque est le premier critère de choix.
     Le type <type>bigint</type> ne doit être utilisé que si le 
     type <type>integer</type> n'offre pas une étendue suffisante
     car le type <type>integer</type> est nettement plus rapide.
    </para>

    <para>
     Le type <type>bigint</type> peut ne pas fonctionner correctement
     sur toutes les plates-formes, car il repose sur la capacité du
     compilateur à supporter les entiers de 8 octets.
     Sur une machine qui ne les supporte pas, <type>bigint</type> se
     comporte comme <type>integer</type> (mais prend bien huit octets
     d'espace de stockage). Cela dit, les auteurs n'ont pas connaissance 
     de plate-forme raisonnable sur laquelle il en va ainsi.
    </para>

    <para>
     <acronym>SQL</acronym> ne définit que les types de données
     <type>integer</type> (ou <type>int</type>),
     <type>smallint</type> et <type>bigint</type>. Les noms
     de types <type>int2</type>, <type>int4</type>, et
     <type>int8</type> sont des extensions, partagées par
     d'autres systèmes de bases de données <acronym>SQL</acronym>.
    </para>

   </sect2>

   <sect2 id="datatype-numeric-decimal">
    <title>Nombres à précision arbitraire</title>

    <indexterm>
     <primary>numeric (data type)</primary>
    </indexterm>

   <indexterm>
    <primary>nombres à virgule flottante</primary>
   </indexterm>

    <indexterm>
     <primary>decimal</primary>
     <see>numeric</see>
    </indexterm>

    <para>
     Le type <type>numeric</type> peut stocker des nombres contenant 
     jusqu'à 1000 chiffres significatifs et effectuer des calculs
     exacts. Il est spécialement recommandé pour stocker les montants
     financiers et autres quantités pour lesquelles l'exactitude est 
     indispensable. Néanmoins, l'arithmétique sur les valeurs
     <type>numeric</type> est très lente comparée aux types entiers ou aux
     types à virgule flottante décrits dans la section suivante.
    </para>

    <para>
     Dans ce qui suit, on utilise les termes suivants&nbsp;:
     l'<firstterm>échelle</firstterm> d'un <type>numeric</type> est le
     nombre de chiffres décimaux de la partie fractionnaire, à droite du
     séparateur de décimales. La 
     <firstterm>précision</firstterm> d'un <type>numeric</type> est le
     nombre total de chiffres significatifs dans le nombre complet, 
     c'est-à-dire le nombre de chiffres de part et d'autre du séparateur.
     Donc, le nombre 23.5141
     a une précision de 6 et une échelle de 4. On peut considérer que 
     les entiers ont une échelle de 0.
   </para>

    <para>
     La précision maximale et l'échelle maximale d'une colonne <type>numeric</type>
     peuvent être toutes deux réglées.
     Pour déclarer une colonne de type numérique, il faut utiliser la
     syntaxe&nbsp;:
<programlisting>NUMERIC(<replaceable>précision</replaceable>, <replaceable>échelle</replaceable>)</programlisting>
     La précision doit être strictement positive, l'échelle positive
     ou NULL.
     Alternativement&nbsp;:
<programlisting>NUMERIC(<replaceable>précision</replaceable>)</programlisting>
     indique une échelle de 0.
<programlisting>NUMERIC</programlisting>
     sans précision ni échelle crée une colonne dans laquelle on
     peut stocker des valeurs de n'importe quelle précision ou
     échelle, dans la limite de la précision implantée. Une colonne de ce type
     n'impose aucune précision à la valeur entrée,
     alors que les colonnes <type>numeric</type> ayant une échelle 
     forcent les valeurs entrées à cette échelle. (Le standard 
     <acronym>SQL</acronym> demande une précision par défaut de 0, 
     c'est-à-dire de forcer la transformation en entiers. Les auteurs
     trouvent cela inutile. Dans un souci de portabilité, 
     il est préférable de toujours indiquer explicitement la précision et
     l'échelle.)
    </para>

    <para>
     Si l'échelle d'une valeur à stocker est supérieure à celle de la colonne, le
     système arrondit la valeur au nombre de décimales indiqué pour la colonne.
     Si le nombre de chiffres à gauche du point
     décimal est supérieur à la différence entre la précision déclarée et l'échelle
     déclarée, une erreur est levée.
    </para>

    <para>
     Les valeurs numériques sont stockées physiquement sans zéro avant ou
     après. Du coup, la précision déclarée et l'échelle de la colonne sont
     des valeurs maximales, pas des allocations fixes (en ce sens, le type
     numérique est plus proche de <type>varchar(<replaceable>n</replaceable>)</type> que
     de <type>char(<replaceable>n</replaceable>)</type>). Le besoin pour le
     stockage réel est de deux octets pour chaque groupe de quatre chiffres
     décimaux, plus cinq à huit octets d'en-tête.
    </para>

    <indexterm>
     <primary>NaN</primary>
     <see>not a number</see>
   </indexterm>

    <indexterm>
     <primary>not a number</primary>
     <secondary>numeric (type de données)</secondary>
    </indexterm>

    <para>
      En plus des valeurs numériques ordinaires, le type <type>numeric</type>
      autorise la valeur spéciale <literal>NaN</literal> qui signifie   
      <quote>not-a-number</quote> (NdT&nbsp;: pas un nombre). Toute opération
      sur <literal>NaN</literal> retourne <literal>NaN</literal>. Pour écrire cette
      valeur comme une constante dans une requête SQL, elle doit être placée
      entre guillemets. Par exemple,
      <literal>UPDATE table SET x = 'NaN'</literal>. En saisie, la chaîne
      <literal>NaN</literal> est reconnue quelque soit
      la casse utilisée.
    </para>

    <note>
     <para>
      Dans la plupart des implémentations du concept <quote>not-a-number</quote>,
      <literal>NaN</literal> est considéré différent de toute valeur numérique
      (ceci incluant <literal>NaN</literal>). Pour autoriser le tri des valeurs
      de type <type>numeric</type> et les utiliser dans des index basés sur le
      tri, <productname>PostgreSQL</productname> traite les valeurs
      <literal>NaN</literal> comme identiques entre elles, mais toutes supérieures
      aux valeurs non <literal>NaN</literal>.
     </para>
    </note>

    <para>
     Les types <type>decimal</type> et <type>numeric</type> sont 
     équivalents. Les deux types sont dans le standard 
     <acronym>SQL</acronym>.
    </para>
   </sect2>


   <sect2 id="datatype-float">
    <title>Types à virgule flottante</title>

    <indexterm zone="datatype-float">
     <primary>real</primary>
    </indexterm>

    <indexterm zone="datatype-float">
     <primary>double precision</primary>
    </indexterm>

    <indexterm>
     <primary>float4</primary>
     <see>real</see>
    </indexterm>

    <indexterm>
     <primary>float8</primary>
     <see>double precision</see>
    </indexterm>

    <indexterm zone="datatype-float">
     <primary>floating point</primary>
    </indexterm>

    <para>
     Les types de données <type>real</type> et <type>double
     precision</type> sont des types numériques inexacts de précision
     variable. En pratique, ils sont généralement conformes à la norme
     <acronym>IEEE</acronym> 754 pour l'arithmétique binaire à 
     virgule flottante (respectivement simple et double précision), 
     dans la mesure où les processeurs, le système d'exploitation et
     le compilateur les supportent.
    </para>

    <para>
     Inexact signifie que certaines valeurs ne peuvent être converties
     exactement dans le format interne. Elles sont, de ce fait, stockées sous
     une forme approchée. Ainsi, stocker puis réafficher ces valeurs
     peut faire apparaître de légers écarts.
     Prendre en compte ces erreurs et la façon dont elles se propagent
     au cours des calculs est le sujet d'une branche entière des
     mathématiques et de l'informatique, qui n'est pas le sujet de ce
     document, à l'exception des points suivants&nbsp;:
     <itemizedlist>
      <listitem>
       <para>
        pour un stockage et des calculs exacts, comme
        pour les valeurs monétaires, le type <type>numeric</type> doit être
	privilégié&nbsp;;
      </para>
      </listitem>

      <listitem>
       <para>
        pour des calculs compliqués avec ces types 
        pour quoi que ce soit d'important, et particulièrement pour
        le comportement aux limites (infini, zéro), l'implantation spécifique
	à la plate-forme doit être étudié avec soin&nbsp;;
       </para>
      </listitem>

      <listitem>
       <para>
        tester l'égalité de deux valeurs à virgule flottante peut ne
        pas donner le résultat attendu.
       </para>
      </listitem>
     </itemizedlist>
    </para>

    <para>
     Sur la plupart des plates-formes, le type <type>real</type> a une
     étendue d'au moins 1E-37 à 1E37 avec une précision d'au moins
     6 chiffres décimaux. Le type <type>double precision</type> a
     généralement une étendue de 1E-307 à 1E+308 avec une précision
     d'au moins 15 chiffres. Les valeurs trop grandes ou trop petites 
     produisent une erreur. Un arrondi peut avoir lieu si la précision
     d'un nombre en entrée est trop grande. Les nombres trop proches
     de zéro qui ne peuvent être représentés autrement que par zéro
     produisent une erreur (underflow).
    </para>

    <indexterm>
     <primary>not a number</primary>
     <secondary>double precision</secondary>
    </indexterm>

    <para>
     En plus des valeurs numériques ordinaires, les types à virgule flottante
     ont plusieurs valeurs spéciales&nbsp;:
<literallayout><literal>Infinity</literal>
<literal>-Infinity</literal>
<literal>NaN</literal></literallayout>
     Elles représentent les valeurs spéciales de l'IEEE 754,
     respectivement <quote>infinity</quote> (NdT&nbsp;: infini),
     <quote>negative infinity</quote> (NdT&nbsp;: infini négatif) et
     <quote>not-a-number</quote> (NdT&nbsp;: pas un nombre) (sur une machine
     dont l'arithmétique à virgule flottante ne suit pas l'IEEE 754, ces
     valeurs ne fonctionnent probablement pas comme espéré). Lorsqu'elles
     sont saisies en tant que constantes dans une commande SQL, ces valeurs
     doivent être placées entre guillemets. Par exemple, <literal>UPDATE
     table SET x = 'Infinity'</literal>. En entrée, ces valeurs sont reconnues
     quelque soit la casse utilisée.
    </para>

    <note>
     <para>
      IEEE754 spécifie que <literal>NaN</literal> ne devrait pas être considéré
      égale à toute autre valeur en virgule flottante (ceci incluant
      <literal>NaN</literal>). Pour permettre le tri des valeurs en virgule
      flottante et leur utilisation dans des index basés sur des arbres,
      <productname>PostgreSQL</productname> traite les valeurs
      <literal>NaN</literal> comme identiques entre elles, mais supérieures
      à toute valeur différente de <literal>NaN</literal>.
     </para>
    </note>

    <para>
     <productname>PostgreSQL</productname> autorise aussi la notation
     <type>float</type> du standard SQL, ainsi que 
     <type>float(<replaceable>p</replaceable>)</type> pour indiquer
     des types numériques inexacts. <replaceable>p</replaceable>
     indique la précision minimale acceptable en chiffres binaires.
     <productname>PostgreSQL</productname> accepte de
     <type>float(1)</type> à <type>float(24)</type>, qu'il transforme en
     type <type>real</type>, et de
     <type>float(25)</type> à <type>float(53)</type>, qu'il transforme en
     type <type>double precision</type>. Toute valeur de 
     <replaceable>p</replaceable> hors de la zone des valeurs possibles
     produit une erreur. <type>float</type> sans précision est compris
     comme <type>double precision</type>.
    </para>

    <note>
     <para>
      Avant <productname>PostgreSQL</productname> 7.4, la précision
      d'un <type>float(<replaceable>p</replaceable>)</type> était
      supposée indiquer une précision en chiffres décimaux.
      Cela a été corrigé pour respecter le standard SQL, qui
      indique que la précision est indiquée en chiffres binaires.
      L'affirmation que les <type>real</type> et les
      <type>double precision</type> ont exactement 24 et 53 bits
      dans la mantisse est correcte pour les implémentations des
      nombres à virgule flottante respectant le standard IEEE.
      Sur les plates-formes non-IEEE, c'est peut-être un peu sous-estimé
      mais, pour plus de simplicité, la gamme de valeurs pour
      <replaceable>p</replaceable> est utilisée sur toutes les
      plates-formes.
     </para>
    </note>

   </sect2>

   <sect2 id="datatype-serial">
    <title>Types seriés</title>

    <indexterm zone="datatype-serial">
     <primary>serial</primary>
    </indexterm>

    <indexterm zone="datatype-serial">
     <primary>bigserial</primary>
    </indexterm>

    <indexterm zone="datatype-serial">
     <primary>serial4</primary>
    </indexterm>

    <indexterm zone="datatype-serial">
     <primary>serial8</primary>
    </indexterm>

    <indexterm>
     <primary>auto-increment</primary>
     <see>serial</see>
    </indexterm>

    <indexterm>
     <primary>séquence</primary>
     <secondary>type serial</secondary>
    </indexterm>

    <para>
     Les types de données <type>serial</type> et <type>bigserial</type>
     ne sont pas de vrais types, mais plutôt un raccourci de notation
     pour créer des colonnes d'identifiants uniques (similaires à la
     propriété <literal>AUTO_INCREMENT</literal> utilisée par d'autres
     SGBD). Dans la version actuelle, indiquer&nbsp;:

<programlisting>CREATE TABLE <replaceable class="parameter">nom_de_table</replaceable> (
    <replaceable class="parameter">nom_de_colonne</replaceable> SERIAL
);</programlisting>

     est équivalent à écrire :

<programlisting>CREATE SEQUENCE <replaceable class="parameter">nom_de_table</replaceable>_<replaceable class="parameter">nom_de_colonne</replaceable>_seq;
CREATE TABLE <replaceable class="parameter">nom_de_table</replaceable> (
    <replaceable class="parameter">nom_de_colonne</replaceable> integer NOT NULL DEFAULT nextval('<replaceable class="parameter">nom_de_table</replaceable>_<replaceable class="parameter">nom_de_colonne</replaceable>_seq') NOT NULL
);
ALTER SEQUENCE <replaceable class="parameter">nom_de_table</replaceable>_<replaceable class="parameter">nom_de_colonne</replaceable>_seq OWNED BY <replaceable class="parameter">nom_de_table</replaceable>.<replaceable class="parameter">nom_de_colonne</replaceable>;</programlisting>

     Une colonne d'entiers a ainsi été créée dont la valeur par défaut
     est assignée par un générateur de
     séquence. Une contrainte <literal>NOT NULL</literal> est ajoutée pour
     s'assurer qu'une valeur NULL ne puisse pas être explicitement 
     insérée. (Dans la plupart des cas, une 
     contrainte <literal>UNIQUE</literal> ou <literal>PRIMARY KEY</literal>
     peut être ajoutée pour
     interdire que des doublons soient créés par accident, mais ce
     n'est pas automatique.) Enfin, la séquence est marquée <quote>owned by</quote>
     (possédée par) la colonne pour qu'elle soit supprimée si la colonne ou
     la table est supprimée.
    </para>

    <note>
     <para>
      Avant <productname>PostgreSQL</productname> 7.3, 
      <type>serial</type> sous-entendait <literal>UNIQUE</literal>.
      Ce n'est plus automatique. Pour qu'une colonne de type
      serial soit unique ou soit une clé primaire, il faut le préciser,
      comme pour les autres types.
     </para>
    </note>

    <para>
     Pour insérer la valeur suivante de la séquence dans la colonne
     <type>serial</type>, il faut préciser que la valeur par
     défaut de la colonne doit être utilisée. Cela peut se faire de deux façons&nbsp;: soit en
     excluant cette colonne de la liste des colonnes de la commande 
     <command>INSERT</command> soit en utilisant le mot clé
     <literal>DEFAULT</literal>.
    </para>

    <para>
     Les types <type>serial</type> et <type>serial4</type> sont
     identiques&nbsp;: ils créent tous les deux des colonnes 
     <type>integer</type>. Les types <type>bigserial</type> et 
     <type>serial8</type> fonctionnent de la même façon mais créent des
     colonnes <type>bigint</type>. <type>bigserial</type> doit
     être utilisé si plus de 2<superscript>31</superscript>
     identifiants sont prévus sur la durée de vie de la table.
    </para>

    <para>
     La séquence créée pour une colonne <type>serial</type> est automatiquement
     supprimée quand la colonne correspondante est supprimée. La séquence peut
     être détruite sans supprimer la colonne, mais 
     la valeur par défaut de la colonne est alors également supprimée.
    </para>
   </sect2>
  </sect1>

  <sect1 id="datatype-money">
   <title>Types monétaires</title>

   <para>
    Le type <type>money</type> stocke un montant en devise avec
    un nombre fixe de décimales. Voir le <xref linkend="datatype-money-table"/>.
    De nombreux formats sont acceptés en entrée, dont les entiers et
    les nombre à virgule flottante, ainsi que les formats classiques
    de devises, comme <literal>'$1,000.00'</literal>. 
    Le format de sortie est généralement dans le dernier format, mais dépend
    de la locale.
    Les valeurs numériques qui ne sont pas entre guillemets peuvent être
    converties dans le type <type>money</type> en convertissant la valeur
    numérique en <type>text</type> puis en <type>money</type>&nbsp;:
<programlisting>
SELECT 1234::text::money;
</programlisting>
    Il n'existe pas de moyen simple de faire l'inverse d'une façon
    indépendante de la locale, donc en convertissant une valeur de type
    <type>money</type> en un type numérique.
    Si vous connaissez le symbole de la monnaie et le séparateur des
    milliers, vous pouvez utiliser <function>regexp_replace()</function>&nbsp;:
<programlisting>
SELECT regexp_replace('52093.89'::money::text, '[$,]', '', 'g')::numeric;
</programlisting>

   </para>

   <para>
    Comme l'affichage de ce type de données est sensible à la casse, charger
    des données du type  <type>money</type> dans une base de données qui a une
    configuration différente de <varname>lc_monetary</varname> pourrait ne pas
    fonctionner. Pour éviter les problèmes, assurez-vous, avant de restaurer une
    sauvegarde, que la variable <varname>lc_monetary</varname> a la même valeur
    ou une valeur équivalente à celle qui était configurée lors de la
    sauvegarde.
   </para>

    <table id="datatype-money-table">
     <title>Types monétaires</title>
     <tgroup cols="4">
     <colspec colnum="1" colwidth="0.7*"/>
     <colspec colnum="2" colwidth="0.7*"/>
     <colspec colnum="3" colwidth="1.3*"/>
     <colspec colnum="4" colwidth="1.3*"/>
      <thead>
       <row>
        <entry>Nom</entry>
        <entry>Taille de stockage</entry>
        <entry>Description</entry>
        <entry>Étendue</entry>
       </row>
      </thead>
      <tbody>
       <row>
        <entry>money</entry>
        <entry>8 octets</entry>
        <entry>montant monétaire</entry>
        <entry>-92233720368547758.08 à +92233720368547758.07</entry>
       </row>
      </tbody>
     </tgroup>
    </table>
  </sect1>


  <sect1 id="datatype-character">
   <title>Types caractère</title>

   <indexterm zone="datatype-character">
    <primary>Chaîne de caractères</primary>
    <secondary>types de données</secondary>
   </indexterm>

   <indexterm>
    <primary>Chaîne</primary>
    <see>Chaîne de caractères</see>
   </indexterm>

   <indexterm zone="datatype-character">
    <primary>character</primary>
   </indexterm>

   <indexterm zone="datatype-character">
    <primary>character varying</primary>
   </indexterm>

   <indexterm zone="datatype-character">
    <primary>text</primary>
   </indexterm>

   <indexterm zone="datatype-character">
    <primary>char</primary>
   </indexterm>

   <indexterm zone="datatype-character">
    <primary>varchar</primary>
   </indexterm>

    <table id="datatype-character-table">
     <title>Types caractère</title>
     <tgroup cols="2">
      <thead>
       <row>
        <entry>Nom</entry>
        <entry>Description</entry>
       </row>
      </thead>
      <tbody>
       <row>
        <entry><type>character varying(<replaceable>n</replaceable>)</type>, <type>varchar(<replaceable>n</replaceable>)</type></entry>
        <entry>Longueur variable avec limite</entry>
       </row>
       <row>
        <entry><type>character(<replaceable>n</replaceable>)</type>, <type>char(<replaceable>n</replaceable>)</type></entry>
        <entry>longueur fixe, complété par des espaces</entry>
       </row>
       <row>
        <entry><type>text</type></entry>
        <entry>longueur variable illimitée</entry>
       </row>
     </tbody>
     </tgroup>
    </table>

   <para>
    Le <xref linkend="datatype-character-table"/> présente les types
    génériques disponibles dans <productname>PostgreSQL</productname>.
   </para>

   <para>
    <acronym>SQL</acronym> définit deux types de caractères principaux&nbsp;:
    <type>character varying(<replaceable>n</replaceable>)</type> et
    <type>character(<replaceable>n</replaceable>)</type> où <replaceable>n</replaceable>
    est un entier positif.
    Ces deux types permettent de stocker des chaînes de caractères de taille
    inférieure ou égale à <replaceable>n</replaceable>. Toute tentative
    d'insértion d'une chaîne plus longue conduit à une erreur, à moins que les 
    caractères en excès ne soient tous des espaces, auquel cas la chaîne 
    est tronquée à la taille maximale (cette exception étrange est imposée
    par la norme <acronym>SQL</acronym>).
    Si la chaîne à stocker est plus petite que la taille déclarée,
    les valeurs de type <type>character</type> sont complétées par des
    espaces, celles de type <type>character varying</type> sont stockées en
    l'état.
   </para>

    <para>
     Si une valeur est explicitement transtypée en  
     <type>character varying(<replaceable>n</replaceable>)</type> ou en
     <type>character(<replaceable>n</replaceable>)</type>, une valeur trop
     longue est tronquée à <replaceable>n</replaceable> caractères sans
     qu'aucune erreur ne soit levée (ce comportement est aussi imposé par
     la norme <acronym>SQL</acronym>.)
    </para>

   <para>
    Les notations <type>varchar(<replaceable>n</replaceable>)</type> et
    <type>char(<replaceable>n</replaceable>)</type> sont des alias de
    <type>character varying(<replaceable>n</replaceable>)</type> et
    <type>character(<replaceable>n</replaceable>)</type>, respectivement.
    <type>character</type> sans indication de taille est équivalent à
    <type>character(1)</type>. Si <type>character varying</type> est
    utilisé sans indicateur de taille, le type accepte des chaînes de
    toute taille. Il s'agit là d'une spécificité de 
    <productname>PostgreSQL</productname>.
   </para>

   <para>
    De plus, <productname>PostgreSQL</productname> propose aussi le type
    <type>text</type>, qui permet de stocker des chaînes de n'importe
    quelle taille. Bien que le type <type>text</type> ne soit pas
    dans le standard <acronym>SQL</acronym>, plusieurs autres systèmes de
    gestion de bases de données SQL le proposent également.
   </para>

<!-- padded : complété, aligné, autre chose ? padding : remplissage -->
<!-- trailing spaces : espaces finales -->
   <para>
    Les valeurs de type <type>character</type> sont complétées physiquement à
    l'aide d'espaces pour atteindre la longueur <replaceable>n</replaceable>
    indiquée. Ces valeurs sont également
    stockées et affichées de cette façon. Les espaces de remplissage
    n'ont, toutefois, aucune signification sémantique. Les espaces finales
    sont ignorées lors de la comparaison de deux valeurs de type
    <type>character</type> et sont supprimées lors de la conversion
    d'une valeur <type>character</type> en un des autres types chaîne. Ces
    espaces <emphasis>ont</emphasis> une signification sémantique pour
    les valeurs de type <type>character varying</type> et <type>text</type>.
   </para>

   <para>
    L'espace nécessaire pour une chaîne de caractères courte (jusqu'à 126 octets)
    est de un octet, plus la taille de la chaîne qui inclut le remplissage avec
    des espaces dans le cas du type <type>character</type>. Les chaînes plus
    longues ont quatre octets d'en-tête au lieu d'un seul. Les chaînes longues
    sont automatiquement compressées par le système, donc le besoin pourrait
    être moindre. Les chaînes vraiment très longues sont stockées dans des
    tables supplémentaires, pour qu'elles n'empêchent pas d'accéder rapidement
    à des valeurs plus courtes.
    Dans tous les cas, la taille maximale possible pour une chaîne de 
    caractères est de l'ordre de 1 Go. (La taille maximale pour 
    <replaceable>n</replaceable> dans la déclaration de type est inférieure.
    Il ne sert à rien de modifier ce comportement, car avec 
    les encodages sur plusieurs octets, les nombres de caractères
    et d'octets peuvent être très différents. Pour stocker
    de longues chaînes sans limite supérieure précise, il est préférable
    d'utiliser les types 
    <type>text</type> et <type>character varying</type> sans 
    taille, plutôt que d'indiquer une limite de taille arbitraire.)
   </para>

   <tip>
    <para>
     Il n'y a aucune différence de performance entre ces trois types, si ce
     n'est la place disque supplémentaire requise pour le type à remplissage
     et quelques cycles CPU supplémentaires pour vérifier la longueur lors du
     stockage dans une colonne contrainte par la taille. Bien que
     <type>character(<replaceable>n</replaceable>)</type> ait des avantages en
     terme de performance sur certains autres systèmes de bases de données, il
     ne dispose pas de ce type d'avantages dans 
     <productname>PostgreSQL</productname>. Dans la plupart des situations,
     les types <type>text</type> et <type>character varying</type> peuvent
     être utilisés à leur place.
    </para>
   </tip>

<!-- string literals 
litteral est un libellé dans le sens "sa valeur est explicitement indiquée par
sa forme" -->
   <para>
    On peut se référer à la <xref linkend="sql-syntax-strings"/> pour obtenir plus d'informations
    sur la syntaxe des libellés de chaînes, et le <xref linkend="functions"/>
    pour des informations complémentaires sur les opérateurs et les fonctions.
    Le jeu de caractères de la base de données détermine celui 
    utilisé pour stocker les valeurs texte&nbsp;; pour plus
    d'informations sur le support des jeux de caractères, se référer à
    la <xref linkend="multibyte"/>.
   </para>

   <example>
    <title>Utilisation des types caractère</title>

<programlisting>CREATE TABLE test1 (a character(4));
INSERT INTO test1 VALUES ('ok');
SELECT a, char_length(a) FROM test1; -- <co id="co.datatype-char"/>
<computeroutput>
  a   | char_length
------+-------------
 ok   |           2
</computeroutput>

CREATE TABLE test2 (b varchar(5));
INSERT INTO test2 VALUES ('ok');
INSERT INTO test2 VALUES ('bien      ');
INSERT INTO test2 VALUES ('trop long');
<computeroutput>ERROR:  value too long for type character varying(5)</computeroutput>
INSERT INTO test2 VALUES ('trop long'::varchar(5)); -- troncature explicite
SELECT b, char_length(b) FROM test2;
<computeroutput>
   b   | char_length
-------+-------------
 ok    |           2
 bien  |           5
 trop  |           5
</computeroutput></programlisting>
    <calloutlist>
     <callout arearefs="co.datatype-char">
      <para>
       La fonction <function>char_length</function> est décrite dans
       la <xref linkend="functions-string"/>.
      </para>
     </callout>
    </calloutlist>
   </example>

   <para>
    Il y a deux autres types caractère de taille fixe dans
    <productname>PostgreSQL</productname>. Ils sont décrits dans le <xref
    linkend="datatype-character-special-table"/>. Le type <type>name</type>
    existe <emphasis>uniquement</emphasis> pour le stockage des identifiants
    dans les catalogues systèmes et n'est pas destiné à être utilisé par
    les utilisateurs normaux. Sa taille est actuellement définie à 64 octets 
    (63 utilisables plus le terminateur) mais doit être référencée en
    utilisant la constante <symbol>NAMEDATALEN</symbol>. La taille est
    définie à la compilation (et est donc ajustable pour des besoins 
    particuliers). La taille maximale par défaut peut éventuellement être
    modifiée dans une
    prochaine version. Le type <type>"char"</type> (attention aux guillemets)
    est différent de <type>char(1)</type> car il n'utilise qu'un seul octet 
    de stockage. Il est utilisé dans les catalogues systèmes comme un type 
    d'énumération économique.
   </para>

    <table id="datatype-character-special-table">
     <title>Types caractères spéciaux</title>
     <tgroup cols="3">
     <colspec colnum="1" colwidth="1*"/>
     <colspec colnum="2" colwidth="1*"/>
     <colspec colnum="3" colwidth="2*"/>
      <thead>
       <row>
        <entry>Nom</entry>
        <entry>Taille de stockage</entry>
        <entry>Description</entry>
       </row>
      </thead>
      <tbody>
       <row>
        <entry><type>"char"</type></entry>
        <entry>1 octet</entry>
        <entry>type interne d'un octet</entry>
       </row>
       <row>
        <entry><type>name</type></entry>
        <entry>64 octets</entry>
        <entry>type interne pour les noms d'objets</entry>
       </row>
      </tbody>
     </tgroup>
    </table>

  </sect1>

 <sect1 id="datatype-binary">
  <title>Types de données binaires</title>

  <indexterm zone="datatype-binary">
   <primary>binary data</primary>
  </indexterm>

  <indexterm zone="datatype-binary">
   <primary>bytea</primary>
  </indexterm>
   <para>
    Le type de données <type>bytea</type> permet de stocker des chaînes
    binaires&nbsp;; voir le <xref linkend="datatype-binary-table"/>.
   </para>

   <table id="datatype-binary-table">
    <title>Types de données binaires</title>
    <tgroup cols="3">
     <colspec colnum="1" colwidth="1*"/>
     <colspec colnum="2" colwidth="1*"/>
     <colspec colnum="3" colwidth="2*"/>
     <thead>
      <row>
       <entry>Nom</entry>
       <entry>Espace de stockage</entry>
       <entry>Description</entry>
      </row>
     </thead>
     <tbody>
      <row>
       <entry><type>bytea</type></entry>
       <entry>un à quatre octets plus la taille de la chaîne binaire à stocker</entry>
       <entry>Chaîne binaire de longueur variable</entry>
      </row>
     </tbody>
    </tgroup>
   </table>

   <para>
    Une chaîne binaire est une séquence d'octets. Les chaînes binaires
    se distinguent des chaînes de caractères par deux caractéristiques&nbsp;:
    tout d'abord, les chaînes binaires permettent de stocker des octets de
    valeurs zéro ainsi que les autres caractères <quote>non imprimables</quote>
    (habituellement, les octets en dehors de l'échelle de 32 à
    126). Les chaînes de caractères interdisent les octets de valeur zéro et
    interdisent aussi toute valeur d'octet ou séquence d'octets invalide
    selon l'encodage sélectionné pour la base
    de données. Ensuite, les opérations sur les chaînes binaires traitent
    réellement les octets alors que le traitement de chaînes de caractères
    dépend de la configuration de la locale. En résumé, les chaînes binaires
    sont appropriées pour le stockage de données que le développeur considère
    comme des <quote>octets bruts</quote> alors que les chaînes de caractères sont
    appropriées pour le stockage de texte.
   </para>

   <para>
    Lors de la saisie de valeurs de type <type>bytea</type>, les octets d'une
    certaine valeur <emphasis>doivent</emphasis> être échappés (mais toutes
    les valeurs <emphasis>peuvent</emphasis> l'être) lorsqu'ils appartiennent
    à une chaîne littérale au sein d'une
    commande <acronym>SQL</acronym>. En général, pour échapper un octet,
    il faut le convertir en nombre octal sur 3 caractères, correspondant à sa
    valeur décimale, et le faire précédé de deux
    antislashs. Le <xref linkend="datatype-binary-sqlesc"/>
    affiche les caractères qui doivent être échappés, et donne les séquences
    d'échappement possibles.
   </para>

   <table id="datatype-binary-sqlesc">
    <title>Octets littéraux <type>bytea</type> à échapper</title>
    <tgroup cols="5">
     <thead>
      <row>
       <entry>Valeur décimale de l'octet</entry>
       <entry>Description</entry>
       <entry>Représentation échappée en entrée</entry>
       <entry>Exemple</entry>
       <entry>Représentation en sortie</entry>
      </row>
     </thead>

     <tbody>
      <row>
       <entry>0</entry>
       <entry>octet zéro</entry>
       <entry><literal>E'\\000'</literal></entry>
       <entry><literal>SELECT E'\\000'::bytea;</literal></entry>
       <entry><literal>\000</literal></entry>
      </row>

      <row>
       <entry>39</entry>
       <entry>apostrophe</entry>
       <entry><literal>''''</literal> or <literal>E'\\047'</literal></entry>
       <entry><literal>SELECT E'\''::bytea;</literal></entry>
       <entry><literal>'</literal></entry>
      </row>

      <row>
       <entry>92</entry>
       <entry>antislash</entry>
       <entry><literal>E'\\\\'</literal> or <literal>E'\\134'</literal></entry>
       <entry><literal>SELECT E'\\\\'::bytea;</literal></entry>
       <entry><literal>\\</literal></entry>
      </row>

      <row>
       <entry>de 0 à 31 et de 127 à 255</entry>
       <entry>octets <quote>non affichables</quote></entry>
       <entry><literal>E'\\<replaceable>xxx'</replaceable></literal> (octal value)</entry>
       <entry><literal>SELECT E'\\001'::bytea;</literal></entry>
       <entry><literal>\001</literal></entry>
      </row>

     </tbody>
    </tgroup>
   </table>

   <para>
    La nécessité d'échapper les octets <quote>non affichables</quote> dépend
    des paramétrages de la locale. Il est parfois possible de s'en sortir sans
    échappement. Le résultat de chacun des
    exemples du <xref linkend="datatype-binary-sqlesc"/> fait exactement
    un octet, même si la représentation en sortie de l'octet zéro et
    de l'antislash font plus d'un caractère.
   </para>

   <para>
    S'il faut écrire tant d'antislashs, comme
    indiqué dans le <xref linkend="datatype-binary-sqlesc"/>, c'est qu'une
    chaîne binaire doit passer à travers deux phases d'analyse dans le
    serveur <productname>PostgreSQL</productname>. Le premier antislash
    de chaque paire est vu comme un caractère d'échappement par
    l'analyseur de chaîne (en supposant que la syntaxe d'échappement des
    chaînes soit utilisée) et est donc consommé, laissant le second antislash
    de la paire. (Les chaînes à guillemets dollar peuvent être utilisées
    pour éviter ce niveau d'échappement.) L'antislash restant est
    compris par la fonction d'entrée de <productname>PostgreSQL</productname>
    comme le début d'une valeur octale sur trois caractères ou comme
    l'échappement d'un autre antislash.
    Par exemple, une chaîne littérale passée au serveur comme
    <literal>E'\\001'</literal> devient <literal>\001</literal> après
    être passée au travers de l'analyseur d'échappement de chaîne.
    Le <literal>\001</literal> est envoyé à la fonction d'entrée de
    <type>bytea</type>, qui le convertit en un octet simple ayant une valeur
    décimale de 1. Le guillemet simple n'est pas traité
    spécialement par <type>bytea</type> et suit les règles normales
    des chaînes littérales de chaîne. Voir aussi la <xref linkend="sql-syntax-strings"/>.
   </para>

   <para>
   Les octets de <type>bytea</type> sont également échappés en sortie. En général,
   tout octet <quote>non-imprimable</quote> est converti en son équivalent
   octal sur trois caractères et précédé d'un antislash.
   La plupart des caractères <quote>imprimables</quote> sont affichés 
   avec leur représentation standard dans le jeu de caractères du client.
   Les octets de valeur décimale 92 (antislash) ont une représentation
   spéciale. Les détails sont dans le
   <xref linkend="datatype-binary-resesc"/>.
   </para>

   <table id="datatype-binary-resesc">
    <title>Octets échappés en sortie pour <type>bytea</type></title>
    <tgroup cols="5">
     <thead>
      <row>
       <entry>Valeur décimale de l'octet</entry>
       <entry>Description</entry>
       <entry>Représentation de sortie échappée</entry>
       <entry>Exemple</entry>
       <entry>Résultat en sortie</entry>
      </row>
     </thead>

     <tbody>

      <row>
       <entry>92</entry>
       <entry>antislash</entry>
       <entry><literal>\\</literal></entry>
       <entry><literal>SELECT E'\\134'::bytea;</literal></entry>
       <entry><literal>\\</literal></entry>
      </row>

      <row>
       <entry>0 à 31 et 127 à 255</entry>
       <entry>octets<quote>non affichables</quote></entry>
       <entry><literal>\<replaceable>xxx</replaceable></literal> (valeur octale)</entry>
       <entry><literal>SELECT E'\\001'::bytea;</literal></entry>
       <entry><literal>\001</literal></entry>
      </row>

      <row>
       <entry>32 à 126</entry>
       <entry>octets <quote>affichables</quote></entry>
       <entry>Représentation dans le jeu de caractères du client</entry>
       <entry><literal>SELECT E'\\176'::bytea;</literal></entry>
       <entry><literal>~</literal></entry>
      </row>

     </tbody>
    </tgroup>
   </table>

   <para>
    En fonction de l'interface utilisée pour accéder à
    <productname>PostgreSQL</productname>, un travail supplémentaire
    d'échappement/de &laquo;&nbsp;déséchappement&nbsp;&raquo; des chaînes
    <type>bytea</type> peut être
    nécessaire. Il faut également  
    échapper les sauts de lignes et retours à la ligne si l'interface les
    traduit automatiquement, par exemple.
   </para>

   <para>
    Le standard <acronym>SQL</acronym> définit un type binaire différent,
    appelé <type>BLOB</type> ou <type>BINARY LARGE OBJECT</type>.
    Le format d'entrée est différent de celui du <type>bytea</type> mais les
    fonctions et opérateurs fournis sont globalement les mêmes.
   </para>
 </sect1>


  <sect1 id="datatype-datetime">
   <title>Types date/heure</title>

   <indexterm zone="datatype-datetime">
    <primary>date</primary>
   </indexterm>
   <indexterm zone="datatype-datetime">
    <primary>time</primary>
   </indexterm>
   <indexterm zone="datatype-datetime">
    <primary>time without time zone</primary>
   </indexterm>
   <indexterm zone="datatype-datetime">
    <primary>time with time zone</primary>
   </indexterm>
   <indexterm zone="datatype-datetime">
    <primary>timestamp</primary>
   </indexterm>
   <indexterm zone="datatype-datetime">
    <primary>timestamp with time zone</primary>
   </indexterm>
   <indexterm zone="datatype-datetime">
    <primary>timestamp without time zone</primary>
   </indexterm>
   <indexterm zone="datatype-datetime">
    <primary>interval</primary>
   </indexterm>
   <indexterm zone="datatype-datetime">
    <primary>time span</primary>
   </indexterm>
   <para>
    <productname>PostgreSQL</productname> supporte l'ensemble des types date
    et heure du <acronym>SQL</acronym>. Ces types sont présentés dans le <xref
    linkend="datatype-datetime-table"/>. Les opérations disponibles sur ces
    types de données sont décrites dans la <xref linkend="functions-datetime"/>.
   </para>

    <table id="datatype-datetime-table">
     <title>Types date et heure</title>
     <tgroup cols="6">
      <thead>
       <row>
        <entry>Nom</entry>
        <entry>Taille de stockage</entry>
        <entry>Description</entry>
        <entry>Valeur minimale</entry>
        <entry>Valeur maximale</entry>
        <entry>Résolution</entry>
       </row>
      </thead>
      <tbody>
       <row>
        <entry><type>timestamp [ (<replaceable>p</replaceable>) ] [ without time zone ]</type></entry>
        <entry>8 octets</entry>
        <entry>date et heure</entry>
        <entry>4713 avant JC</entry>
        <entry>5874897 après JC</entry>
        <entry>1 microseconde / 14 chiffres</entry>
       </row>
       <row>
        <entry><type>timestamp [ (<replaceable>p</replaceable>) ] with time zone</type></entry>
        <entry>8 octets</entry>
        <entry>date et heure, avec fuseau horaire</entry>
        <entry>4713 avant JC</entry>
        <entry>5874897 après JC</entry>
        <entry>1 microseconde / 14 chiffres</entry>
       </row>
       <row>
        <entry><type>interval [ (<replaceable>p</replaceable>) ]</type></entry>
        <entry>12 octets</entry>
        <entry>intervalle de temps</entry>
        <entry>-178000000 années</entry>
        <entry>178000000 années</entry>
	<entry>1 microseconde / 14 chiffres</entry>
       </row>
       <row>
        <entry><type>date</type></entry>
        <entry>4 octets</entry>
        <entry>date seule</entry>
        <entry>4713 avant JC</entry>
        <entry>5874897 après JC</entry>
        <entry>1 jour</entry>
       </row>
       <row>
        <entry><type>time [ (<replaceable>p</replaceable>) ] [ without time zone ]</type></entry>
        <entry>8 octets</entry>
        <entry>heure seule</entry>
        <entry>00:00:00.00</entry>
        <entry>24:00:00</entry>
	<entry>1 microseconde / 14 chiffres</entry>
       </row>
       <row>
        <entry><type>time [ (<replaceable>p</replaceable>) ] with time zone</type></entry>
        <entry>12 octets</entry>
        <entry>heure seule, avec fuseau horaire</entry>
        <entry>00:00:00+1459</entry>
        <entry>24:00:00-1459</entry>
	<entry>1 microseconde / 14 chiffres</entry>
       </row>
      </tbody>
     </tgroup>
    </table>

   <note>
    <para>
     Précédemment à <productname>PostgreSQL</productname> 7.3, n'écrire que
     <type>timestamp</type> équivalait à <type>timestamp with
     time zone</type>. Cela a été modifié pour des raisons de compatibilité avec
     le standard SQL.
    </para>
   </note>

   <para>
    <type>time</type>, <type>timestamp</type>, et
    <type>interval</type> acceptent une précision optionnelle
    <replaceable>p</replaceable>, qui indique le nombre de
    décimales pour les secondes. Il n'y a pas, par défaut, de
    limite explicite à cette précision. Les valeurs acceptées pour
    <replaceable>p</replaceable> s'étendent de 0 à 6 pour les types
    <type>timestamp</type> et <type>interval</type>.
   </para>

<!-- SAS : 2007 03 29
Il y a là qqch d'assez compliqué à comprendre pour le néophyte, et
tout autant pour moi...
Pourquoi stocker des valeurs dont l'étendue court de 4000 BC à 30 000 AC comme
des références au 1er janvier 2000 ? 
-->
   <note>
    <para>
     Quand les valeurs <type>timestamp</type> sont stockées en tant que nombre à
     virgule flottante de précision double (par défaut à l'heure actuelle), la limite réelle de la
     précision peut être inférieure à 6. Les valeurs 
     <type>timestamp</type> sont stockées comme un nombre de secondes avant
     ou après le 1er janvier 2000 à minuit. La précision à la microseconde est
     obtenue pour les dates proches du 1er janvier 2000, mais elle se
     dégrade pour les dates plus éloignées. Quand les valeurs 
     <type>timestamp</type> sont stockées sur des entiers de huit octets
     (une option de compilation), la précision en microseconde
     est disponible sur toute l'étendue de valeurs. Néanmoins, les valeurs
     de type timestamp codées sur des entiers de huit octets ont une
     échelle de date plus restreinte que celle indiquée ci-dessus&nbsp;: de
     4713 avant Jésus-Christ à 294276 après Jésus-Christ. La même option
     de compilation détermine si les valeurs <type>time</type> et
     <type>interval</type> sont stockées comme nombres à virgule
     flottante ou comme entiers sur huit octets. Dans le cas de la
     virgule flottante, la précision des grandes valeurs <type>interval</type>
     se dégradent à mesure que l'intervalle croît.
    </para>
   </note>

   <para>
    Pour les types <type>time</type>, l'intervalle accepté pour
    <replaceable>p</replaceable> s'étend de 0 à 6 pour les entiers sur
    8 octets et de 0 à 10 pour les nombres à virgule flottante.
   </para>

   <para>
    Le type <type>time with time zone</type> est défini dans le standard
    SQL mais sa définition lui prête des propriétés qui font douter de son
    utilité. Dans la plupart des cas, une combinaison de <type>date</type>,
    <type>time</type>, <type>timestamp without time zone</type> et
    <type>timestamp with time zone</type> devrait permettre de résoudre
    toutes les fonctionnalités de date et heure nécessaires à une application.
   </para>

   <para>
    Les types <type>abstime</type> et <type>reltime</type> sont des types de
    précision moindre, utilisés en interne. Il n'est pas recommandé de les
    utiliser dans de nouvelles applications. Au contraire, il est souhaitable
    de migrer l'existant vers un autre type approprié.
    Il est probable que l'un ou l'autre (voire tous) de ces types internes 
    disparaisse(nt) dans une future version.
   </para>

   <sect2 id="datatype-datetime-input">
    <title>Saisie des dates et heures</title>

    <para>
     La saisie de dates et heures peut se faire dans la plupart des formats
     raisonnables, dont ISO8601, tout format compatible avec
     <acronym>SQL</acronym>, le format <productname>POSTGRES</productname>
     traditionnel ou autres.
     Pour certains formats, l'ordre des jours, mois et années en entrée est ambigu.
     Il est alors possible de préciser l'ordre attendu pour ces champs.
     Le paramètre <xref linkend="guc-datestyle"/> peut être positionné à
     <literal>MDY</literal> pour choisir
     une interprétation mois-jour-année, à <literal>DMY</literal> pour jour-mois-année
     ou à <literal>YMD</literal> pour année-mois-jour.
    </para>

    <para>
     <productname>PostgreSQL</productname> est plus flexible que la norme
     <acronym>SQL</acronym> ne l'exige pour la manipulation des dates et
     des heures. Voir l'<xref linkend="datetime-appendix"/> pour connaître
     les règles exactes de reconnaissance des dates et heures et les formats
     reconnus pour les champs texte comme les mois, les jours de la
     semaine et les fuseaux horaires.
    </para>

    <para>
     Tout libellé de date ou heure saisi doit être placé
     entre apostrophes, comme les chaînes de caractères.
     La <xref linkend="sql-syntax-constants-generic"/> peut être consultée pour
     plus d'information. <acronym>SQL</acronym> requiert la syntaxe suivante&nbsp;:
<synopsis><replaceable>type</replaceable> [ (<replaceable>p</replaceable>) ] '<replaceable>valeur</replaceable>'</synopsis>
     où <replaceable>p</replaceable>, précision optionnelle, est un entier
     correspondant au nombre de décimales du champ secondes.
     La précision peut être précisée pour les types <type>time</type>,
     <type>timestamp</type>, et <type>interval</type>.
     Les valeurs admissibles sont mentionnées plus haut. Si aucune précision
     n'est indiquée dans une déclaration de constante, celle de la valeur
     littérale est utilisée.
    </para>

    <sect3>
    <title>Dates</title>

    <indexterm>
     <primary>date</primary>
    </indexterm>
 
    <para>
     Le <xref linkend="datatype-datetime-date-table"/> regroupe les formats
     de date possibles pour la saisie de valeurs de type <type>date</type>.
    </para>

     <table id="datatype-datetime-date-table">
      <title>Saisie de date</title>
      <tgroup cols="2">
       <colspec colnum="1" colwidth="1*"/>
       <colspec colnum="2" colwidth="5*"/>
       <thead>
        <row>
         <entry>Exemple</entry>
         <entry>Description</entry>
        </row>
           </thead>
           <tbody>
        <row>
         <entry>January 8, 1999</entry>
         <entry>sans ambiguïté quel que soit le style de date 
         (<varname>datestyle</varname>)</entry>
        </row>
        <row>
         <entry>1999-01-08</entry>
         <entry>ISO-8601&nbsp;; 8 janvier, quel que soit le mode
         (format recommandé)</entry>
        </row>
        <row>
         <entry>1/8/1999</entry>
         <entry>8 janvier en mode <literal>MDY</literal>&nbsp;;
          1er août en mode <literal>DMY</literal></entry>
        </row>
        <row>
         <entry>1/18/1999</entry>
         <entry>18 janvier en mode <literal>MDY</literal>&nbsp;;
          rejeté dans les autres modes</entry>
        </row>
        <row>
         <entry>01/02/03</entry>
         <entry>2 janvier 2003 en mode <literal>MDY</literal>&nbsp;;
          1er février 2003 en mode <literal>DMY</literal>&nbsp;;
          3 février 2001 en mode <literal>YMD</literal>
         </entry>
        </row>
        <row>
         <entry>1999-Jan-08</entry>
         <entry>8 janvier dans tous les modes</entry>
        </row>
        <row>
         <entry>Jan-08-1999</entry>
         <entry>8 janvier dans tous les modes</entry>
        </row>
        <row>
         <entry>08-Jan-1999</entry>
         <entry>8 janvier dans tous les modes</entry>
        </row>
        <row>
         <entry>99-Jan-08</entry>
         <entry>8 janvier en mode <literal>YMD</literal>, erreur sinon</entry>
        </row>
        <row>
         <entry>08-Jan-99</entry>
         <entry>8 janvier, sauf en mode <literal>YMD</literal>&nbsp;: erreur</entry>
        </row>
        <row>
         <entry>Jan-08-99</entry>
         <entry>8 janvier, sauf en mode <literal>YMD</literal>&nbsp;: erreur</entry>
        </row>
        <row>
         <entry>19990108</entry>
         <entry>ISO-8601&nbsp;; 8 janvier 1999 dans tous les modes</entry>
        </row>
        <row>
         <entry>990108</entry>
         <entry>ISO-8601&nbsp;; 8 janvier 1999 dans tous les modes</entry>
        </row>
        <row>
         <entry>1999.008</entry>
         <entry>Année et jour de l'année</entry>
        </row>
        <row>
         <entry>J2451187</entry>
         <entry>Jour du calendrier Julien</entry>
        </row>
        <row>
         <entry>January 8, 99 BC</entry>
         <entry>année 99 avant Jésus Christ</entry>
        </row>
      </tbody>
     </tgroup>
    </table>
   </sect3>

    <sect3>
     <title>Heures</title>

     <indexterm>
      <primary>heure</primary>
     </indexterm>
     <indexterm>
      <primary>heure sans fuseau horaire</primary>
     </indexterm>
     <indexterm>
      <primary>heure avec fuseau horaire</primary>
     </indexterm>

     <para>
      Les types heure-du-jour sont 
      <type>time [ (<replaceable>p</replaceable>) ] without time zone</type> et
      <type>time [ (<replaceable>p</replaceable>) ] with time zone</type>.
      <type>time</type> est équivalent à <type>time without time zone</type>.
     </para>

     <para>
      Les saisies valides pour ces types sont constituées d'une heure
      suivie éventuellement d'un fuseau horaire (voir le <xref
      linkend="datatype-datetime-time-table"/> et le <xref
      linkend="datatype-timezone-table"/>). Si un fuseau est précisé
      pour le type <type>time without time zone</type>, il est ignoré sans
      message d'erreur. Si une date est indiquée, elle
      est ignorée sauf si un fuseau horaire impliquant une règle de changement
      d'heure (heure d'été/heure d'hiver) est précisé,
      <literal>America/New_York</literal> par exemple.
      Dans ce cas, la date est nécessaire pour pouvoir déterminer la règle de
      calcul de l'heure qui s'applique.
      Le décalage approprié du
      fuseau horaire est enregistré dans la valeur de
      <type>time with time zone</type>.
     </para>

      <table id="datatype-datetime-time-table">
       <title>Saisie d'heure</title>
       <tgroup cols="2">
        <colspec colnum="1" colwidth="1*"/>
        <colspec colnum="2" colwidth="4*"/>
        <thead>
         <row>
          <entry>Exemple</entry>
          <entry>Description</entry>
         </row>
        </thead>
        <tbody>
         <row>
          <entry><literal>04:05:06.789</literal></entry>
          <entry>ISO 8601</entry>
         </row>
         <row>
          <entry><literal>04:05:06</literal></entry>
          <entry>ISO 8601</entry>
         </row>
         <row>
          <entry><literal>04:05</literal></entry>
          <entry>ISO 8601</entry>
         </row>
         <row>
          <entry><literal>040506</literal></entry>
          <entry>ISO 8601</entry>
         </row>
         <row>
          <entry><literal>04:05 AM</literal></entry>
          <entry>Identique à 04:05&nbsp;; AM n'affecte pas la valeur</entry>
         </row>
         <row>
          <entry><literal>04:05 PM</literal></entry>
          <entry>Identique à 16:05&nbsp;; l'heure doit être &lt;= 12</entry>
         </row>
         <row>
          <entry><literal>04:05:06.789-8</literal></entry>
          <entry>ISO 8601</entry>
         </row>
         <row>
          <entry><literal>04:05:06-08:00</literal></entry>
          <entry>ISO 8601</entry>
         </row>
         <row>
          <entry><literal>04:05-08:00</literal></entry>
          <entry>ISO 8601</entry>
         </row>
         <row>
          <entry><literal>040506-08</literal></entry>
          <entry>ISO 8601</entry>
         </row>
         <row>
          <entry><literal>04:05:06 PST</literal></entry>
          <entry>fuseau horaire abrégé</entry>
         </row>
         <row>
          <entry><literal>2003-04-12 04:05:06 America/New_York</literal></entry>
	  <entry>fuseau horaire en nom complet</entry>
         </row>
        </tbody>
       </tgroup>
      </table>

      <table tocentry="1" id="datatype-timezone-table">
       <title>Saisie des fuseaux horaires</title>
       <tgroup cols="2">
        <colspec colnum="1" colwidth="1*"/>
        <colspec colnum="2" colwidth="4*"/>
        <thead>

         <row>
          <entry>Exemple</entry>
          <entry>Description</entry>
         </row>
        </thead>
        <tbody>
         <row>
          <entry>PST</entry>
          <entry>Abréviation pour l'heure standard du Pacifique (Pacific Standard Time)</entry>
         </row>
         <row>
          <entry><literal>America/New_York</literal></entry>
	  <entry>Nom complet du fuseau horaire</entry>
         </row>
         <row>
          <entry><literal>PST8PDT</literal></entry>
          <entry>Nommage POSIX du fuseau horaire</entry>
         </row>
         <row>
          <entry>-8:00</entry>
          <entry>Décalage ISO-8601 pour la zone PST</entry>
         </row>
         <row>
          <entry>-800</entry>
          <entry>Décalage ISO-8601 pour la zone PST</entry>
         </row>
         <row>
          <entry>-8</entry>
          <entry>Décalage ISO-8601 pour la zone PST</entry>
         </row>
         <row>
          <entry><literal>zulu</literal></entry>
          <entry>Abréviation militaire de GMT</entry>
         </row>
         <row>
          <entry><literal>z</literal></entry>
          <entry>Version courte de <literal>zulu</literal></entry>
         </row>
        </tbody>
       </tgroup>
      </table>

      <para>
       L'<xref linkend="datatype-timezones"/> apporte des précisions quant à
       la façon d'indiquer les fuseaux horaires.
      </para>
    </sect3>

    <sect3>
    <title>Horodatage</title>

    <indexterm>
     <primary>timestamp</primary>
    </indexterm>

    <indexterm>
     <primary>timestamp with time zone</primary>
    </indexterm>

    <indexterm>
     <primary>timestamp without time zone</primary>
    </indexterm>

    <indexterm>
     <primary>horodatage</primary>
    </indexterm>

    <indexterm>
     <primary>estampille temporelle</primary>
    </indexterm>

<!-- AD : After Death, après JC
     BD : Before Death, avant JC -->
     <para>
      Les saisies valides sont constituées de la concaténation
      d'une date et d'une heure, éventuellement suivie d'un fuseau horaire et d'un
      qualificatif <literal>AD</literal> (après Jésus Christ) ou
      <literal>BC</literal>  (avant Jésus Christ).
      (<literal>AD</literal>/<literal>BC</literal> peut aussi apparaître avant le
      fuseau horaire mais ce n'est pas l'ordre préféré.)
      Ainsi&nbsp;:

<programlisting>1999-01-08 04:05:06</programlisting>
      et&nbsp;:
<programlisting>1999-01-08 04:05:06 -8:00</programlisting>

      sont des valeurs valides, qui suivent le standard 
      <acronym>ISO</acronym> 8601. Le format très courant&nbsp;:

<programlisting>January 8 04:05:06 1999 PST</programlisting>
      est également supporté.
     </para>

     <para>
      Le standard <acronym>SQL</acronym> différencie les libéllés
      <type>timestamp without time zone</type> et
      <type>timestamp with time zone</type> par la présence d'un
      <quote>+</quote> ou d'un <quote>-</quote>. De ce fait, d'après le
      standard, 
<programlisting>TIMESTAMP '2004-10-19 10:23:54'</programlisting>
      est du type <type>timestamp without time zone</type> alors que
      <programlisting>TIMESTAMP '2004-10-19 10:23:54+02'</programlisting>
      est du type <type>timestamp with time zone</type>.
      <productname>PostgreSQL</productname> n'examine jamais le contenu
      d'un libellé avant de déterminer son type. Du coup, il
      traite les deux ci-dessus comme des valeurs de type
      <type>timestamp without time zone</type>. Pour s'assurer qu'un
      littéral est traité comme une valeur de type 
      <type>timestamp with time zone</type>, il faut préciser explicitement 
      le bon type&nbsp;:
<programlisting>TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02'</programlisting>
      Dans un libellé de type
      <type>timestamp without time zone</type>,
      <productname>PostgreSQL</productname> ignore
      silencieusement toute indication de fuseau horaire. C'est-à-dire que
      la valeur résultante est dérivée des champs date/heure de la valeur
      saisie et n'est pas corrigée par le fuseau horaire.
     </para>

     <para>
      Pour <type>timestamp with time zone</type>, la valeur stockée en interne
      est toujours en UTC (<foreignphrase>Universal Coordinated
      Time</foreignphrase> ou Temps Universel Coordonné), aussi
      connu sous le nom de <acronym>GMT</acronym> (<foreignphrase>Greenwich
      Mean Time</foreignphrase>).
      Les valeurs saisies avec un fuseau horaire explicite sont converties
      en UTC à l'aide du décalage approprié. Si aucun fuseau horaire
      n'est précisé, alors le système considère que la date est dans le fuseau
      horaire indiqué par le paramètre système <xref linkend="guc-timezone"/>,
      et la convertit en UTC en utilisant le décalage de la zone 
      <varname>timezone</varname>.
     </para>

     <para>
      Quand une valeur <type>timestamp with time zone</type> est affichée, 
      elle est toujours convertie de l'UTC vers le fuseau horaire courant
      (variable <varname>timezone</varname>), et affichée comme une heure locale.
      Pour voir l'heure dans un autre fuseau horaire, il faut, soit changer la
      valeur de <varname>timezone</varname>, soit utiliser la construction
      <literal>AT TIME ZONE</literal> (voir la
      <xref linkend="functions-datetime-zoneconvert"/>).
     </para>

     <para>
      Les conversions entre <type>timestamp without time zone</type> et
      <type>timestamp with time zone</type> considèrent normalement
      que la valeur <type>timestamp without time zone</type> utilise
      le fuseau horaire <varname>timezone</varname>. Un fuseau différent
      peut être choisi en utilisant <literal>AT TIME ZONE</literal>.
     </para>
    </sect3>

    <sect3>
     <title>Intervalles</title>

     <indexterm>
      <primary>interval</primary>
     </indexterm>

      <para>
       Les valeurs de type <type>interval</type> utilisent la syntaxe
       suivante&nbsp;:

<programlisting><optional>@</optional> <replaceable>quantité</replaceable> <replaceable>unité</replaceable> <optional><replaceable>quantité</replaceable> <replaceable>unité</replaceable>...</optional> <optional><replaceable>direction</replaceable></optional></programlisting>

      où&nbsp;: <replaceable>quantité</replaceable> est un nombre (éventuellement
      signé)&nbsp;; <replaceable>unité</replaceable> est
      <literal>microsecond</literal>, <literal>millisecond</literal>,
      <literal>second</literal>,
      <literal>minute</literal>, <literal>hour</literal>, <literal>day</literal>,
      <literal>week</literal>, <literal>month</literal>, <literal>year</literal>,
      <literal>decade</literal>, <literal>century</literal>, <literal>millennium</literal>,
      une abbréviation ou un pluriel de ces unités&nbsp;;
      <replaceable>direction</replaceable> peut être <literal>ago</literal> ou
      vide. L'arobase (<literal>@</literal>) est optionnel. Les valeurs
      des différentes unités sont implicitement ajoutées en utilisant le signe
      approprié.
     </para>

     <para>
      Les nombres de jours, heures, minutes et secondes peuvent être précisées
      sans unité explicite. Par exemple <literal>'1 12:59:10'</literal> est
      compris de la même façon que
      <literal>'1 day 12 hours 59 min 10 sec'</literal> (1 jour, 12 heures,
      59 minutes, 10 secondes).
     </para>

     <para>
      La précision optionnelle, en dessous de la seconde, doit être
      comprise entre 0 et
      6, et prend la précision du libellé saisi comme valeur par défaut.
     </para>

     <para>
      En interne, les valeurs <type>interval</type> sont enregistrées comme des mois,
      jours et secondes. Ceci parce que le nombre de jours d'un mois varie et
      qu'un jour peut avoir 23 ou 25 heures si un changement d'heure s'applique.
      Comme les intervalles sont habituellement créés à partir de chaînes de
      caractères constantes ou de soustraction de <type>timestamp</type>,
      cette méthode de stockage fonctionne bien dans la majorité des cas. Les
      fonctions <function>justify_days</function> et <function>justify_hours</function> sont
      disponibles pour ajuster les jours et les heures qui dépassent leurs
      périodes habituelles.
     </para>
    </sect3>

    <sect3>
     <title>Valeurs spéciales</title>

     <indexterm>
      <primary>heure</primary>
      <secondary>constantes</secondary>
     </indexterm>

     <indexterm>
      <primary>date</primary>
      <secondary>constantes</secondary>
     </indexterm>

     <para>
      <productname>PostgreSQL</productname> supporte plusieurs
      valeurs de dates spéciales, dans un souci de simplification. Ces valeurs
      sont présentées dans le
      <xref linkend="datatype-datetime-special-table"/>.
      Les valeurs <literal>infinity</literal> et <literal>-infinity</literal>
      ont une représentation spéciale dans le système et sont affichées
      ainsi&nbsp;; les autres ne sont que des raccourcies de notation
      convertis en dates/heures ordinaires lorsqu'ils sont 
      lus. (En particulier, <literal>now</literal> et les chaînes relatives sont
      converties en une valeur de temps spécifique à leur lecture).
      Toutes ces valeurs doivent être écrites entre simples quotes
      lorsqu'elles sont utilisées comme des constantes dans les commandes SQL.
     </para>

      <table id="datatype-datetime-special-table">
       <title>Saisie de dates/heures spéciales</title>
       <tgroup cols="2">
        <thead>
         <row>
          <entry>Saisie</entry>
          <entry>Types valides</entry>
          <entry>Description</entry>
         </row>
        </thead>
       
        <tbody>
         <row>
          <entry><literal>epoch</literal></entry>
          <entry><type>date</type>, <type>timestamp</type></entry>
          <entry>1970-01-01 00:00:00+00 (date système zéro d'Unix)</entry>
         </row>
         <row>
          <entry><literal>infinity</literal></entry>
          <entry><type>timestamp</type></entry>
          <entry>plus tard que toutes les autres dates</entry>
         </row>
         <row>
          <entry><literal>-infinity</literal></entry>
          <entry><type>timestamp</type></entry>
          <entry>plus tôt que toutes les autres dates</entry>
         </row>
         <row>
          <entry><literal>now</literal></entry>
          <entry><type>date</type>, <type>time</type>, <type>timestamp</type></entry>
          <entry>heure de démarrage de la transaction courante</entry>
         </row>
         <row>
          <entry><literal>today</literal></entry>
          <entry><type>date</type>, <type>timestamp</type></entry>
          <entry>aujourd'hui minuit</entry>
         </row>
         <row>
          <entry><literal>tomorrow</literal></entry>
          <entry><type>date</type>, <type>timestamp</type></entry>
          <entry>demain minuit</entry>
         </row>
         <row>
          <entry><literal>yesterday</literal></entry>
          <entry><type>date</type>, <type>timestamp</type></entry>
          <entry>hier minuit</entry>
         </row>
         <row>
          <entry><literal>allballs</literal></entry>
          <entry><type>time</type></entry>
          <entry>00:00:00.00 UTC</entry>
         </row>
        </tbody>

       </tgroup>
      </table>

      <para>
       Les fonctions suivantes, compatibles avec le standard 
       <acronym>SQL</acronym>, peuvent aussi être utilisées pour obtenir
       l'heure courante pour le type de données correspondant&nbsp;:
       <literal>CURRENT_DATE</literal>, <literal>CURRENT_TIME</literal>, 
       <literal>CURRENT_TIMESTAMP</literal>, <literal>LOCALTIME</literal>, 
       <literal>LOCALTIMESTAMP</literal>. Les quatre derniers acceptent une
       indication optionnelle de précision en dessous de la seconde (voir
       la <xref linkend="functions-datetime-current"/>). Ce
       sont là des fonctions SQL qui ne sont <emphasis>pas</emphasis> reconnues
       comme chaînes de saisie de données.
      </para>

    </sect3>
   </sect2>

   <sect2 id="datatype-datetime-output">
    <title>Affichage des dates et heures</title>

    <indexterm>
     <primary>date</primary>
     <secondary>format d'affichage</secondary>
     <seealso>formatage</seealso>
    </indexterm>

    <indexterm>
     <primary>heure</primary>
     <secondary>format de sortie</secondary>
     <seealso>formatage</seealso>
    </indexterm>

    <para>
     Le format de sortie des types date/heure peut être positionné à l'un des
     quatre formats de date suivants&nbsp;: ISO 8601, <acronym>SQL</acronym> 
     (Ingres), traditionnel POSTGRES et German (germanique). Cela se fait à l'aide de la commande
     <literal>SET datestyle</literal>. Le format par défaut est le format
     <acronym>ISO</acronym>. (Le standard <acronym>SQL</acronym> impose l'utilisation du format
     ISO 8601. Le nom du format d'affichage <quote>SQL</quote>
     est un accident historique.) Le
     <xref linkend="datatype-datetime-output-table"/>  présente des exemples de
     chaque format d'affichage. La sortie d'un type <type>date</type> ou
     <type>time</type> n'est évidemment composée que de la partie date ou heure, comme
     montré dans les exemples.
    </para>

     <table id="datatype-datetime-output-table">
      <title>Styles d'affichage de date/heure</title>
      <tgroup cols="3">
       <thead>
        <row>
    
        <entry>Spécification de style</entry>
       <entry>Description</entry>
       <entry>Exemple</entry>
       </row>

       </thead>
       <tbody>
        <row>

         <entry>ISO</entry>
         <entry>standard ISO 8601/SQL</entry>
         <entry>1997-12-17 07:37:16-08</entry>
        </row>
        <row>

         <entry>SQL</entry>
         <entry>style traditionnel</entry>
         <entry>12/17/1997 07:37:16.00 PST</entry>
        </row>
        <row>

     <entry>POSTGRES</entry>
     <entry>style original</entry>
     <entry>Wed Dec 17 07:37:16 1997 PST</entry>
    </row>
    <row>

     <entry>German</entry>
     <entry>style régional</entry>
     <entry>17.12.1997 07:37:16.00 PST</entry>
    </row>

       </tbody>
      </tgroup>
     </table>

    <para>
     Dans les styles <acronym>SQL</acronym> et POSTGRES, les jours
     apparaissent avant le mois si l'ordre des champs DMY a été précisé,
     sinon les mois apparaissent avant les jours
     (voir la <xref linkend="datatype-datetime-input"/>  pour savoir comment
     ce paramètre affecte l'interprétation des valeurs en entrée). Le
     <xref linkend="datatype-datetime-output2-table"/> présente un exemple.
    </para>

     <table id="datatype-datetime-output2-table">
      <title>Convention de présentation des dates</title>
      <tgroup cols="3">
       <thead>
        <row>
         <entry>Valeur de <varname>datestyle</varname> (style de date)</entry>
         <entry>Ordre de saisie</entry>
         <entry>Exemple d'affichage</entry>
        </row>
       </thead>
       <tbody>
        <row>
         <entry><literal>SQL, DMY</literal></entry>
         <entry><replaceable>jour</replaceable>/<replaceable>mois</replaceable>/<replaceable>année</replaceable></entry>
         <entry>17/12/1997 15:37:16.00 CET</entry>
        </row>
        <row>
         <entry><literal>SQL, MDY</literal></entry>
         <entry><replaceable>mois</replaceable>/<replaceable>jour</replaceable>/<replaceable>année</replaceable></entry>
         <entry>12/17/1997 07:37:16.00 PST</entry>
        </row>
        <row>
         <entry><literal>Postgres, DMY</literal></entry>
         <entry><replaceable>jour</replaceable>/<replaceable>mois</replaceable>/<replaceable>année</replaceable></entry>
         <entry>Wed 17 Dec 07:37:16 1997 PST</entry>
        </row>
       </tbody>
      </tgroup>
     </table>

    <para>
     L'affichage du type <type>interval</type> ressemble au format de saisie,
     à ceci près que les unités comme <literal>century</literal> ou
     <literal>week</literal> sont converties en années et jours, et que
     <literal>ago</literal> est converti en un signe approprié. En mode ISO,
     l'affichage ressemble à&nbsp;:
<programlisting><optional> <replaceable>quantité</replaceable> <replaceable>unité</replaceable> <optional> ... </optional> </optional> <optional> <replaceable>jours</replaceable> </optional> <optional> <replaceable>heures</replaceable>:<replaceable>minutes</replaceable>:<replaceable>secondes</replaceable> </optional></programlisting>
    </para>

    <para>
     Les styles de date/heure peuvent être sélectionnés à l'aide de la
     commande <command>SET datestyle</command>, du paramètre
     <xref linkend="guc-datestyle"/> du fichier de configuration
     <filename>postgresql.conf</filename> ou par la variable 
     d'environnement <envar>PGDATESTYLE</envar> sur le serveur ou le client.
     La fonction de formatage <function>to_char</function> (voir <xref 
     linkend="functions-formatting"/>) permet de formater les affichages
     de date/heure de manière plus flexible.
    </para>
   </sect2>

   <sect2 id="datatype-timezones">
    <title>Fuseaux horaires</title>

    <indexterm zone="datatype-timezones">
     <primary>fuseau horaire</primary>
    </indexterm>

    <para>
     Les fuseaux horaires et les conventions liées sont influencées
     par des décisions politiques, pas uniquement par la géométrie de la terre.
     Les fuseaux horaires se sont quelque peu standardisés au cours du
     vingtième siècle mais continuent à être soumis à des changements
     arbitraires, particulièrement en respect des règles de changement
     d'heure (heure d'été/heure d'hiver).
     <productname>PostgreSQL</productname> gère actuellement les règles de
     changement d'heure pour la période de 1902 à 2038 (qui correspond à
     l'intégralité de l'échelle du temps système Unix). Les heures en dehors de
     cette échelle sont prises dans le <quote>temps standard</quote> du
     fuseau horaire sélectionné, quelque soit la partie de l'année où elles
     tombent.
    </para>

    <para>
     <productname>PostgreSQL</productname> se veut compatible avec les
     définitions standard <acronym>SQL</acronym> pour un usage typique.
     Néanmoins, le standard <acronym>SQL</acronym> possède un mélange 
     étrange de types de date/heure et de possibilités. Deux problèmes 
     évidents sont&nbsp;:

     <itemizedlist>
      <listitem>
       <para>
        bien que le type <type>date</type> n'ait pas de fuseau horaire
        associé, le type <type>heure</type> peut en avoir un.
        Les fuseaux horaires, dans le monde réel, ne peuvent avoir de sens
        qu'associés à une date et à une heure, vu que l'écart peut varier
        avec l'heure d'été&nbsp;;
       </para>
      </listitem>

      <listitem>
       <para>
        le fuseau horaire par défaut est précisé comme un écart numérique constant
        avec l'<acronym>UTC</acronym>. Il n'est, de ce fait, pas possible de s'adapter à l'heure 
        d'été ou d'hiver lorsque l'on fait des calculs arithmétiques qui passent
        les limites de l'heure d'été et de l'heure d'hiver.
       </para>
      </listitem>

     </itemizedlist>
    </para>

    <para>
     Pour éviter ces difficultés, il est recommandé d'utiliser des
     types date/heure qui contiennent à la fois une date et une heure
     lorsque les fuseaux horaires sont utilisés. Il est également préférable
     de <emphasis>ne pas</emphasis> utiliser le type
     <type>time with time zone</type>. (Ce type est néanmoins proposé par 
     <productname>PostgreSQL</productname> pour les applications
     existantes et pour assurer la compatibilité avec le standard
     <acronym>SQL</acronym>.)
     <productname>PostgreSQL</productname> utilise le fuseau horaire local
     pour tous les types qui ne contiennent qu'une date ou une heure.
    </para>

    <para>
     Toutes les dates et heures liées à un fuseau horaire sont stockées
     en interne en <acronym>UTC</acronym>. Elles sont converties en heure
     locale dans le fuseau indiqué par le paramètre de configuration <xref
     linkend="guc-timezone"/> avant d'être affiché sur le client.
    </para>

    <para>
     <productname>PostgreSQL</productname> permet d'indiquer les fuseaux
     horaires de trois façons différentes&nbsp;:
     <itemizedlist>
      <listitem>
       <para>
        un nom complet de fuseau horaire, par exemple <literal>America/New_York</literal>.
	Les noms reconnus de fuseau horaire sont listés dans la vue
        <literal>pg_timezone_names</literal> (voir <xref
        linkend="view-pg-timezone-names"/>).
        <productname>PostgreSQL</productname> utilise les données
        <literal>zic</literal> pour cela, les mêmes noms sont donc
	reconnus par de nombreux autres logiciels&nbsp;;
       </para>
      </listitem>
      <listitem>
       <para>
        une abréviation de fuseau horaire, par exemple <literal>PST</literal>.
	Une telle indication ne définit qu'un décalage particulier
	à partir d'UTC, en contraste avec les noms complets de fuseau horaire
	qui peuvent aussi impliquer un ensemble de dates pour le changement
	d'heure. Les abréviations reconnues sont listées dans la vue
	<literal>pg_timezone_abbrevs</literal> (voir <xref
        linkend="view-pg-timezone-abbrevs"/>). Les paramètres de configuration
	<xref linkend="guc-timezone"/> et <xref linkend="guc-log-timezone"/> ne
	peuvent pas être configurés à l'aide
	d'une abréviation de fuseau horaire, mais ces abréviations peuvent
	être utilisées dnas les saisies de date/heure et avec l'opérateur
        <literal>AT TIME ZONE</literal>&nbsp;;
       </para>
      </listitem>
      <listitem>
       <para>
        une spécification POSIX de fuseau sous la forme 
	<replaceable>STD</replaceable><replaceable>décalage</replaceable> ou
	<replaceable>STD</replaceable><replaceable>décalage</replaceable><replaceable>DST</replaceable>
	avec <replaceable>STD</replaceable> une abréviation de fuseau et
	<replaceable>décalage</replaceable> un décalage numérique en nombre
	d'heures à l'ouest d'UTC et <replaceable>DST</replaceable> une abréviation
	optionnelle de changement d'heure, à interpréter comme une heure avant
	le décalage donné. Par exemple si <literal>EST5EDT</literal> n'est pas
	déjà reconnu comme fuseau horaire, il est accepté et est
	fonctionnellement équivalent à l'heure du fuseau de la côte est des
	USA. Si un nom de changement d'heure est présent, il
	est interprété selon les règles régissant les changements d'heure
	utilisées dans l'entrée <filename>posixrules</filename> de la base
	de données des fuseaux horaires, <literal>zic</literal>. Dans une
	installation <productname>PostgreSQL</productname> standard,
        <filename>posixrules</filename> est identique à <literal>US/Eastern</literal>,
        pour que les spécifications POSIX des fuseaux horaires correspondent
	aux règles de changements d'heure aux États-Unis. Ce comportement
	peut, au besoin, être ajusté en remplaçant le fichier
        <filename>posixrules</filename>.

       </para>
      </listitem>
     </itemizedlist>

     Il y a une différence conceptuelle et pratique entre les abréviations et
     les noms complets&nbsp;: les abréviations représentent toujours un décalage
     fixe par rapport à UTC alors que la plupart des noms complets impliquent une règle de
     changement d'heure et donc deux décalages possibles.
    </para>

    <para>
     La fonctionnalité des fuseaux horaires POSIX peut accepter silencieusement
     des saisies erronées car il n'y a
     pas de vérification des abréviations de fuseaux horaires. Par
     exemple, <literal>SET TIMEZONE TO FOOBAR0</literal> fonctionne mais
     conduit le système à utiliser en réalité une abréviation très
     particulière d'UTC.
     Un autre problème à conserver en tête est que, pour les noms des fuseaux
     horaires POSIX, les décalages positifs sont utilisés pour les emplacements
     situés à l'<emphasis>ouest</emphasis> de Greenwich. Partout ailleurs,
     <productname>PostgreSQL</productname> suit la convention ISO-8601 pour qui
     les décalages positifs de fuseaux horaires concernent
     l'<emphasis>est</emphasis> de Greenwich.
    </para>

    <para>
     Dans tous les cas, les noms des fuseaux horaires sont
     insensibles à la casse. (C'est un changement par rapport aux versions
     de <productname>PostgreSQL</productname> antérieures à la 8.2 qui étaient
     sensibles à la casse dans certains cas et pas dans d'autres.)
    </para>

    <para>
     Ni les noms complets ni les abréviations ne sont codés en dur dans le
     serveur&nbsp;; ils sont obtenus à partir des fichiers de configuration
     stockés sous <filename>.../share/timezone/</filename> et
     <filename>.../share/timezonesets/</filename> du répertoire d'installation
     (voir <xref linkend="datetime-config-files"/>).
    </para>

    <para>
     Le paramètre de configuration <xref linkend="guc-timezone"/> peut être
     fixé dans le fichier <filename>postgresql.conf</filename> ou par tout
     autre moyen standard décrit dans le <xref linkend="runtime-config"/>.
     Il existe aussi quelques manières spéciales de le configurer&nbsp;:

     <itemizedlist>
      <listitem>
       <para>
        si <varname>timezone</varname> n'est précisé ni dans
        <filename>postgresql.conf</filename> ni comme une option en ligne de commande
        du serveur, le serveur tente d'utiliser la valeur de la variable
        d'environnement <envar>TZ</envar> comme fuseau horaire par défaut.
        Si <envar>TZ</envar> n'est pas définie ou ne fait pas partie des noms
        de fuseau horaire connus par <productname>PostgreSQL</productname>,
        le serveur tente de déterminer le fuseau horaire par défaut du
        système d'exploitation en vérifiant le comportement de la fonction
        <literal>localtime()</literal> de la bibliothèque C. Le fuseau horaire par
        défaut est sélectionné comme la correspondance la plus proche parmi
        les fuseaux horaires connus par
	<productname>PostgreSQL</productname>&nbsp;;
        (Ces règles sont aussi utilisées pour choisir la valeur par défaut de
        <xref linkend="guc-log-timezone"/>, si elle n'est pas précisée.)
       </para>
      </listitem>

      <listitem>
       <para>
        la commande <acronym>SQL</acronym> <command>SET TIME ZONE</command>
        configure le fuseau horaire pour une session. C'est une autre façon
        d'indiquer <command>SET TIMEZONE TO</command> avec une syntaxe plus
        compatible avec les spécifications SQL&nbsp;;
       </para>
      </listitem>

      <listitem>
       <para>
        la variable d'environnement <envar>PGTZ</envar>, si le client la
	positionne, est utilisée par les applications fondées sur 
        <application>libpq</application> pour envoyer une commande 
        <command>SET TIME ZONE</command> au serveur lors de la connexion.
       </para>
      </listitem>
     </itemizedlist>
    </para>

   </sect2>

   <sect2 id="datatype-datetime-internals">
    <title>Types internes</title>

    <para>
    <productname>PostgreSQL</productname> utilise les dates du calendrier Julien pour tous
    les calculs de date/heure. Elles ont la propriété intéressante de permettre
    le calcul de toute date depuis 4713 avant Jésus Christ jusque loin dans le futur,
    avec pour seule hypothèse que l'année dure 365,2425 jours.
    </para>

    <para>
     Les conventions pour les dates antérieures au 19ème siècle sont d'une
     lecture intéressante mais ne sont pas assez cohérentes pour être codées
     dans un gestionnaire de dates.
    </para>
   </sect2>

  </sect1>

  <sect1 id="datatype-boolean">
   <title>Type booléen</title>

   <indexterm zone="datatype-boolean">
    <primary>boolean</primary>
    <secondary>type de données</secondary>
   </indexterm>

   <indexterm zone="datatype-boolean">
    <primary>true</primary>
   </indexterm>

   <indexterm zone="datatype-boolean">
    <primary>false</primary>
   </indexterm>

   <para>
    <productname>PostgreSQL</productname> fournit le type <type>boolean</type>
    du standard <acronym>SQL</acronym>.
    Ce type ne dispose que deux états&nbsp;:<quote>true</quote> (vrai) 
    et <quote>false</quote> (faux). Un troisième état, <quote>unknown</quote>
    (inconnu), est représenté par la valeur <acronym>SQL</acronym> NULL.
   </para>

   <para>
    Les libellés valides pour l'état <quote>vrai</quote> sont&nbsp;:
    <simplelist>
     <member><literal>TRUE</literal></member>
     <member><literal>'t'</literal></member>
     <member><literal>'true'</literal></member>
     <member><literal>'y'</literal></member>
     <member><literal>'yes'</literal></member>
     <member><literal>'1'</literal></member>
    </simplelist>
    Pour l'état <quote>faux</quote>, il s'agit de&nbsp;:
    <simplelist>
     <member><literal>FALSE</literal></member>
     <member><literal>'f'</literal></member>
     <member><literal>'false'</literal></member>
     <member><literal>'n'</literal></member>
     <member><literal>'no'</literal></member>
     <member><literal>'0'</literal></member>
    </simplelist>
    Les espaces avant et après sont ignorés.
    Il est recommandé d'utiliser <literal>TRUE</literal> et
    <literal>FALSE</literal> (qui sont compatibles avec la norme 
    <acronym>SQL</acronym>).
   </para>

   <example id="datatype-boolean-example">
    <title>Utilisation du type <type>boolean</type>.</title>

<programlisting>CREATE TABLE test1 (a boolean, b text);
INSERT INTO test1 VALUES (TRUE, 'sic est');
INSERT INTO test1 VALUES (FALSE, 'non est');
SELECT * FROM test1;
 a |    b
---+---------
 t | sic est
 f | non est

SELECT * FROM test1 WHERE a;
 a |    b
---+---------
 t | sic est</programlisting>
   </example>

   <para>
   L'<xref linkend="datatype-boolean-example"/> montre que
   les valeurs booléennes sont affichées avec les lettres
   <literal>t</literal> et <literal>f</literal>.
   </para>

   <para>
    Le type <type>boolean</type> utilise 1 octet de stockage.
   </para>
  </sect1>

  <sect1 id="datatype-enum">
   <title>Types énumération</title>

   <indexterm zone="datatype-enum">
    <primary>data type</primary>
    <secondary>énumération (enum)</secondary>
   </indexterm>

   <para>
    Les types énumérés (enum) sont des types de données qui comprennent un
    ensemble statique, prédéfini de valeurs dans un ordre spécifique. Ils sont
    équivalents aux types <type>enum</type> dans de nombreux langages de
    programmation. Les jours de la semaine ou un ensemble de valeurs de statut
    pour un type de données sont de bons exemples de type enum.
   </para>

   <sect2>
    <title>Déclaration de types énumérés</title>

    <para>
     Les types enum sont créés en utilisant la commande <xref
     linkend="sql-createtype" endterm="sql-createtype-title"/>.
     Par exemple&nbsp;:

<programlisting>
CREATE TYPE mood AS ENUM ('sad', 'ok', 'happy');
</programlisting>

     Une fois créé, le type enum peut être utilisé dans des définitions de
     table et de fonction, comme tous les autres types&nbsp;:
    </para>

    <example>
     <title>Utilisation basique de enum</title>
<programlisting>
CREATE TYPE humeur AS ENUM ('triste', 'ok', 'heureux');
CREATE TABLE personne (
    nom text,
    humeur_actuelle humeur
);
INSERT INTO personne VALUES ('Moe', 'heureux');
SELECT * FROM personne WHERE humeur_actuelle = 'heureux';
 name | humeur_actuelle
------+-----------------
 Moe  | heureux
(1 row)
</programlisting>
     </example>
    </sect2>

    <sect2>
     <title>Tri</title>

     <para>
      L'ordre des valeurs dans un type enum correspond à l'ordre dans lequel
      les valeurs sont présentées lors de la déclaration du type. Tous les
      opérateurs de comparaison et les fonctions d'agrégats relatives peuvent
      être utilisés avec des types enum. Par exemple&nbsp;:
     </para>

     <example>
      <title>Tri d'un enum</title>
<programlisting>
INSERT INTO personne VALUES ('Larry', 'triste');
INSERT INTO personne VALUES ('Curly', 'heureux');
SELECT * FROM personne WHERE humeur_actuelle > 'triste';
 nom   | humeur_actuelle
-------+-----------------
 Moe   | happy
 Curly | ok
(2 rows)

SELECT * FROM personne WHERE humeur_actuelle > 'triste' ORDER BY humeur_actuelle;
 nom   | humeur_actuelle 
-------+--------------
 Curly | ok
 Moe   | happy
(2 rows)

SELECT nom FROM personne
  WHERE humeur_actuelle = (SELECT MIN(humeur_actuelle) FROM personne);
 nom
-------
 Larry
(1 row)
</programlisting>
    </example>
   </sect2>

   <sect2>
    <title>Surêté du type</title>

    <para>
     Les types énumérés sont des types de données complètement séparés et
     peuvent ne pas être comparables entre eux.
    </para>

    <example>
     <title>Manque de conversion</title>
<programlisting>
CREATE TYPE niveau_de_joie AS ENUM ('heureux', 'très heureux', 'ecstatique');
CREATE TABLE vacances (
    nombre_de_semaines int,
    niveau_de_joie niveau_de_joie
);
INSERT INTO vacances(nombre_de_semaines,niveau_de_joie) VALUES (4, 'heureux');
INSERT INTO vacances(nombre_de_semaines,niveau_de_joie) VALUES (6, 'très heureux');
INSERT INTO vacances(nombre_de_semaines,niveau_de_joie) VALUES (8, 'ecstatique');
INSERT INTO vacances(nombre_de_semaines,niveau_de_joie) VALUES (2, 'triste');
ERROR:  invalid input value for enum niveau_de_joie: "triste"
SELECT personne.nom, vacances.nombre_de_semaines FROM personne, vacances
  WHERE personne.humeur_actuelle = vacances.niveau_de_joie;
ERROR:  operator does not exist: humeur = niveau_de_joie
</programlisting>
    </example>

    <para>
     Si vous avez vraiment besoin de ce type de conversion, vous pouvez soit
     écrire un opérateur personnalisé soit ajouter des conversions explicites
     dans votre requête&nbsp;:
    </para>

    <example>
     <title>Comparer différent enums en convertissant en texte</title>
<programlisting>
SELECT personne.nom, vacances.nombre_de_semaines FROM personne, vacances
  WHERE personne.humeur_actuelle::text = vacances.niveau_de_joie::text;
 nom  | nombre_de_semaines 
------+--------------------
 Moe  |         4
(1 row)

</programlisting>
    </example>
   </sect2>

   <sect2>
    <title>Détails d'implémentation</title>
    
    <para>
     Une valeur enum occupe quatre octets sur disque. La longueur du label texte
     d'une valeur enum est limité au paramètre <symbol>NAMEDATALEN</symbol>
     codé en dur dans <productname>PostgreSQL</productname>&nbsp;; dans les
     constructions standards, cela signifie un maximum de 63 octets.
    </para>

    <para>
     Les labels enum sont sensibles à la casse, donc
     <type>'heureux'</type> n'est pas identique à <type>'HEUREUX'</type>.
     Les espaces sont aussi significatifs dans les labels.
    </para>

   </sect2>
  </sect1>

  <sect1 id="datatype-geometric">
<title>Types géométriques</title>

   <para>
    Les types de données géométriques représentent des objets à deux 
    dimensions. Le <xref linkend="datatype-geo-table"/> liste les types 
    disponibles dans <productname>PostgreSQL</productname>.
    Le type le plus fondamental, le point, est à la base de tous les
    autres types.
   </para>

    <table id="datatype-geo-table">
     <title>Types géométriques</title>
     <tgroup cols="4">
      <colspec colnum="1" colwidth="0.7*"/>
      <colspec colnum="2" colwidth="0.7*"/>
      <colspec colnum="3" colwidth="1.3*"/>
      <colspec colnum="4" colwidth="1.3*"/>
      <thead>
       <row>
        <entry>Nom</entry>
        <entry>Taille de stockage</entry>
        <entry>Représentation</entry>
        <entry>Description</entry>
       </row>
      </thead>
      <tbody>
       <row>
        <entry><type>point</type></entry>
        <entry>16 octets</entry>
        <entry>Point du plan</entry>
        <entry>(x,y)</entry>
       </row>
       <row>
        <entry><type>line</type></entry>
        <entry>32 octets</entry>
        <entry>Ligne infinie (pas entièrement implanté)</entry>
        <entry>((x1,y1),(x2,y2))</entry>
       </row>
       <row>
        <entry><type>lseg</type></entry>
        <entry>32 octets</entry>
        <entry>Segment de droite fini</entry>
        <entry>((x1,y1),(x2,y2))</entry>
       </row>
       <row>
        <entry><type>box</type></entry>
        <entry>32 octets</entry>
        <entry>Boîte rectangulaire</entry>
        <entry>((x1,y1),(x2,y2))</entry>
       </row>
       <row>
        <entry><type>path</type></entry>
        <entry>16+16n octets</entry>
        <entry>Chemin fermé (similaire à un polygone)</entry>
        <entry>((x1,y1),...)</entry>
       </row>
       <row>
        <entry><type>path</type></entry>
        <entry>16+16n octets</entry>
        <entry>Chemin ouvert</entry>
        <entry>[(x1,y1),...]</entry>
       </row>
       <row>
        <entry><type>polygon</type></entry>
        <entry>40+16n octets</entry>
        <entry>Polygone (similaire à un chemin fermé)</entry>
        <entry>((x1,y1),...)</entry>
       </row>
       <row>
        <entry><type>circle</type></entry>
        <entry>24 octets</entry>
        <entry>Cercle</entry>
        <entry>&lt;(x,y),r&gt; (centre et rayon)</entry>
       </row>
      </tbody>
     </tgroup>
    </table>

   <para>
    Un large ensemble de fonctions et d'opérateurs permettent d'effectuer
    différentes opérations géométriques, comme l'échelonnage, la translation,
    la rotation, la détermination des intersections. Elles sont expliquées dans
    la <xref linkend="functions-geometry"/>.
   </para>

   <sect2>
    <title>Points</title>

    <indexterm>
     <primary>point</primary>
    </indexterm>

    <para>
     Les points sont les briques fondamentales des types géométriques.
     Les valeurs de type <type>point</type> sont indiquées à l'aide des syntaxes
     suivantes&nbsp;:
<synopsis>( <replaceable>x</replaceable> , <replaceable>y</replaceable> )
  <replaceable>x</replaceable> , <replaceable>y</replaceable></synopsis>

     où <replaceable>x</replaceable> et <replaceable>y</replaceable> sont les coordonnées respectives
     sous forme de nombre à virgule flottante.
    </para>

    <para>
     Les points sont affichés en utilisant la première syntaxe.
    </para>
   </sect2>

   <sect2>
    <title>Segments de droite</title>

    <indexterm>
     <primary>lseg</primary>
    </indexterm>

    <indexterm>
     <primary>ligne</primary>
    </indexterm>

    <para>
     Les segments de droite (<type>lseg</type>) sont représentés sous la forme de
     paires de points à l'aide d'une des syntaxes suivantes&nbsp;:
 
<synopsis>[ ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ( <replaceable>x2</replaceable> , <replaceable>y2</replaceable> ) ]
 ( ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ( <replaceable>x2</replaceable> , <replaceable>y2</replaceable> ) )
  ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ( <replaceable>x2</replaceable> , <replaceable>y2</replaceable> )
     <replaceable>x1</replaceable> , <replaceable>y1</replaceable>   ,   <replaceable>x2</replaceable> , <replaceable>y2</replaceable></synopsis>

     où
     <literal>(<replaceable>x1</replaceable>,<replaceable>y1</replaceable>)</literal>
     et
     <literal>(<replaceable>x2</replaceable>,<replaceable>y2</replaceable>)</literal>
     sont les points aux extrémités du segment.
    </para>

    <para>
     Les segments de droites sont affichés en utilisant la première syntaxe.
    </para>
   </sect2>

<!-- Boîte ou boite ? -->
   <sect2>
    <title>Boîtes</title>

    <indexterm>
     <primary>boîte (type de données)</primary>
    </indexterm>

    <indexterm>
     <primary>rectangle</primary>
    </indexterm>


    <para>
     Les boîtes (rectangles) sont représentées par les paires de points des coins
     opposés de la boîte selon l'une des syntaxes suivante&nbsp;:

<synopsis>( ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ( <replaceable>x2</replaceable> , <replaceable>y2</replaceable> ) )
  ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ( <replaceable>x2</replaceable> , <replaceable>y2</replaceable> )  
    <replaceable>x1</replaceable> , <replaceable>y1</replaceable>   ,   <replaceable>x2</replaceable> , <replaceable>y2</replaceable></synopsis>

     où
     <literal>(<replaceable>x1</replaceable>,<replaceable>y1</replaceable>)</literal>
     et
     <literal>(<replaceable>x2</replaceable>,<replaceable>y2</replaceable>)</literal>
     sont les coins opposés du rectangle.
    </para>

    <para>
     Les rectangles sont affichés en utilisant la deuxième syntaxe.
    </para>

    <para>
     Tous les coins opposés peuvent être saisis, mais les valeurs seront
     réordonnées pour stocker les coins en haut à droite, et en bas à gauche,
     dans cet ordre.
    </para>
   </sect2>

   <sect2>
    <title>Chemins</title>

    <indexterm>
     <primary>path (type de données)</primary>
    </indexterm>

    <para>
     Les chemins ( type <type>path</type> )
     sont représentés par des listes de points connectés.
     Ils peuvent être <firstterm>ouverts</firstterm>, si le premier et
     le dernier point ne sont pas considérés connectés, ou <firstterm>fermés</firstterm>,
     si le premier et le dernier point sont considérés connectés.
    </para>

    <para>
     Les valeurs de type <type>path</type> sont saisies avec une des syntaxes
     suivantes&nbsp;:

<synopsis>[ ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ... , ( <replaceable>xn</replaceable> , <replaceable>yn</replaceable> ) ]
 ( ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ... , ( <replaceable>xn</replaceable> , <replaceable>yn</replaceable> ) )
   ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ... , ( <replaceable>xn</replaceable> , <replaceable>yn</replaceable> )
   ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable>   , ... ,   <replaceable>xn</replaceable> , <replaceable>yn</replaceable> )
     <replaceable>x1</replaceable> , <replaceable>y1</replaceable>   , ... ,   <replaceable>xn</replaceable> , <replaceable>yn</replaceable></synopsis>

    où les points sont les extrémités des segments de droite qui forment
    le chemin. Les crochets (<literal>[]</literal>) indiquent un chemin ouvert
    alors que les parenthèses (<literal>()</literal>) indiquent un chemin fermé.
    Quand les parenthèses externes sont omises, comme dans les syntaxes 3 à 5,
    il est supposé qu'il s'agit d'un chemin fermé.
    </para>

    <para>
     Les chemins sont affichés selon la première syntaxe.
    </para>
   </sect2>

   <sect2>
    <title>Polygones</title>

    <indexterm>
     <primary>polygon</primary>
    </indexterm>

    <para>
     Les polygones ( type <type>polygon</type>) sont représentés par des
     listes de points (les vertex du polygone). Ils peuvent probablement
     être considérés comme des chemins fermés, mais ils sont stockés différemment
     et disposent de leurs propres routines de manipulation.
    </para>

    <para>
     Les valeurs de type <type>polygon</type> sont saisies selon une des
     syntaxes suivantes&nbsp;:

<synopsis>( ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ... , ( <replaceable>xn</replaceable> , <replaceable>yn</replaceable> ) )
  ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ... , ( <replaceable>xn</replaceable> , <replaceable>yn</replaceable> )  
  ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable>   , ... ,   <replaceable>xn</replaceable> , <replaceable>yn</replaceable> )  
    <replaceable>x1</replaceable> , <replaceable>y1</replaceable>   , ... ,   <replaceable>xn</replaceable> , <replaceable>yn</replaceable>    </synopsis>

     où les points sont les extrémités des segments de droite
     qui forment les limites du polygone.
    </para>

    <para>
     Les polygones sont affichés selon la première syntaxe.
    </para>
   </sect2>

   <sect2>
    <title>Cercles</title>

    <indexterm>
     <primary>circle</primary>
    </indexterm>

    <para>
     Les cercles (type <type>circle</type>) sont représentés par un point
     central et un rayon.
     Les valeurs de type <type>circle</type> sont saisies selon une des
     syntaxes suivantes&nbsp;:

<synopsis>&lt; ( <replaceable>x</replaceable> , <replaceable>y</replaceable> ) , <replaceable>r</replaceable> &gt;
( ( <replaceable>x</replaceable> , <replaceable>y</replaceable> ) , <replaceable>r</replaceable> )
  ( <replaceable>x</replaceable> , <replaceable>y</replaceable> ) , <replaceable>r</replaceable>  
    <replaceable>x</replaceable> , <replaceable>y</replaceable>   , <replaceable>r</replaceable>  </synopsis>

     où
     <literal>(<replaceable>x</replaceable>,<replaceable>y</replaceable>)</literal>
     est le centre et <replaceable>r</replaceable> le rayon du cercle.
    </para>

    <para>
     Les cercles sont affichés selon la première syntaxe.
    </para>
   </sect2>

  </sect1>

  <sect1 id="datatype-net-types">
   <title>Types adresses réseau</title>

   <indexterm zone="datatype-net-types">
    <primary>réseau</primary>
    <secondary>types de données</secondary>
   </indexterm>

   <para>
    <productname>PostgreSQL</productname> propose des types de données pour stocker des
    adresses IPv4, IPv6 et MAC. Ceux-ci sont décrits dans le
    <xref linkend="datatype-net-types-table"/>.
    Il est préférable d'utiliser ces types plutôt que des types texte
    standard pour stocker les adresses réseau car ils offrent un contrôle
    de syntaxe lors de la saisie et plusieurs opérateurs et fonctions
    spécialisées (voir la <xref linkend="functions-net"/>).
   </para>

    <table tocentry="1" id="datatype-net-types-table">
     <title>Types d'adresses réseau</title>
     <tgroup cols="3">
      <thead>
       <row>
        <entry>Nom</entry>
        <entry>Taille de stockage</entry>
        <entry>Description</entry>
       </row>
      </thead>
      <tbody>

       <row>
        <entry><type>cidr</type></entry>
        <entry>7 ou 19 octets</entry>
        <entry>réseaux IPv4 et IPv6</entry>
       </row>

       <row>
        <entry><type>inet</type></entry>
        <entry>7 ou 19 octets</entry>
        <entry>hôtes et réseaux IPv4 et IPv6</entry>
       </row>

       <row>
        <entry><type>macaddr</type></entry>
        <entry>6 octets</entry>
        <entry>adresses MAC</entry>
       </row>

      </tbody>
     </tgroup>
    </table>

   <para>
    Lors du tri de données de types <type>inet</type> ou <type>cidr</type>,
    les adresses IPv4 apparaissent toujours avant les adresses IPv6,
    y compris les adresses IPv4 encapsulées, comme
    ::10.2.3.4 ou ::ffff:10.4.3.2.
   </para>


   <sect2 id="datatype-inet">
    <title><type>inet</type></title>

    <indexterm>
     <primary>inet (type de données)</primary>
    </indexterm>

    <para>
     Le type <type>inet</type> stocke une adresse d'hôte IPv4 ou IPv6
     et, optionnellement, l'identité de son sous-réseau, le tout dans un
     seul champ. L'identité du sous-réseau est représentée en indiquant
     combien de bits de l'adresse hôte constituent l'adresse réseau
     (le <quote>masque réseau</quote>).
     Si le masque réseau est 32 et l'adresse de type IPv4,
     alors la valeur n'indique pas un sous-réseau, juste un hôte.
     En IPv6, la longueur de l'adresse est de 128 bits, si bien que 
     128 bits définissent une adresse réseau unique. Pour n'accepter que des
     adresses réseau, il est préférable
     d'utiliser le type <type>cidr</type> plutôt que le type <type>inet</type>.
    </para>

    <para>
      Le format de saisie pour ce type est 
      <replaceable class="parameter">adresse/y</replaceable>
      où
      <replaceable class="parameter">adresse</replaceable>
      est une adresse IPv4 ou IPv6 et
      <replaceable class="parameter">y</replaceable>
      est le nombre de bits du masque réseau.
      Si <replaceable class="parameter">y</replaceable>
      est omis, alors le masque vaut 32 pour IPv4 et
      128 pour IPv6, et la valeur représente un hôte unique.
      À l'affichage, la portion
      <replaceable class="parameter">/y</replaceable>
      est supprimée si le masque réseau indique un hôte unique.
    </para>
   </sect2>

   <sect2 id="datatype-cidr">
    <title><type>cidr</type></title>

    <indexterm>
     <primary>cidr</primary>
    </indexterm>

    <para>
     Le type <type>cidr</type> stocke une définition de réseau 
     IPv4 ou IPv6. La saisie et l'affichage suivent les conventions
     Classless Internet Domain Routing.
     Le format de saisie d'un réseau est
     <replaceable class="parameter">address/y</replaceable> où
     <replaceable class="parameter">address</replaceable> est le réseau représenté sous forme
     d'une adresse IPv4 ou IPv6 et
     <replaceable class="parameter">y</replaceable> est le nombre de bits du masque réseau.
     Si <replaceable class="parameter">y</replaceable> est omis, il calculé en
     utilisant les règles de l'ancien système de classes d'adresses,
     à ceci près qu'il est au moins assez grand pour inclure tous
     les octets saisis. Saisir une adresse réseau
     avec des bits positionnés à droite du masque indiqué est une erreur.
    </para>

    <para>
     <xref linkend="datatype-net-cidr-table"/> présente quelques exemples.
    </para>

     <table id="datatype-net-cidr-table">
      <title>Exemples de saisie de types <type>cidr</type></title>
      <tgroup cols="3">
       <thead> 
        <row> 
         <entry>Saisie <type>cidr</type></entry>
         <entry>Affichage <type>cidr</type></entry>
         <entry><literal><function>abbrev</function>(<type>cidr</type>)</literal></entry>
        </row>
       </thead>
       <tbody>
        <row>
         <entry>192.168.100.128/25</entry>
         <entry>192.168.100.128/25</entry>
         <entry>192.168.100.128/25</entry>
        </row>
        <row>
         <entry>192.168/24</entry>
         <entry>192.168.0.0/24</entry>
         <entry>192.168.0/24</entry>
        </row>
        <row>
         <entry>192.168/25</entry>
         <entry>192.168.0.0/25</entry>
         <entry>192.168.0.0/25</entry>
        </row>
        <row>
         <entry>192.168.1</entry>
         <entry>192.168.1.0/24</entry>
         <entry>192.168.1/24</entry>
        </row>
        <row>
         <entry>192.168</entry>
         <entry>192.168.0.0/24</entry>
         <entry>192.168.0/24</entry>
        </row>
        <row>
         <entry>128.1</entry>
         <entry>128.1.0.0/16</entry>
         <entry>128.1/16</entry>
        </row>
        <row>
         <entry>128</entry>
         <entry>128.0.0.0/16</entry>
         <entry>128.0/16</entry>
        </row>
        <row>
         <entry>128.1.2</entry>
         <entry>128.1.2.0/24</entry>
         <entry>128.1.2/24</entry>
        </row>
        <row>
         <entry>10.1.2</entry>
         <entry>10.1.2.0/24</entry>
         <entry>10.1.2/24</entry>
        </row>
        <row>
         <entry>10.1</entry>
         <entry>10.1.0.0/16</entry>
         <entry>10.1/16</entry>
        </row>
        <row>
         <entry>10</entry>
         <entry>10.0.0.0/8</entry>
         <entry>10/8</entry>
        </row>
        <row>
         <entry>10.1.2.3/32</entry>
         <entry>10.1.2.3/32</entry>
         <entry>10.1.2.3/32</entry>
        </row>
        <row>
         <entry>2001:4f8:3:ba::/64</entry>
         <entry>2001:4f8:3:ba::/64</entry>
         <entry>2001:4f8:3:ba::/64</entry>
        </row>
        <row>
         <entry>2001:4f8:3:ba:2e0:81ff:fe22:d1f1/128</entry>
         <entry>2001:4f8:3:ba:2e0:81ff:fe22:d1f1/128</entry>
         <entry>2001:4f8:3:ba:2e0:81ff:fe22:d1f1</entry>
        </row>
        <row>
         <entry>::ffff:1.2.3.0/120</entry>
         <entry>::ffff:1.2.3.0/120</entry>
         <entry>::ffff:1.2.3/120</entry>
        </row>
        <row>
         <entry>::ffff:1.2.3.0/128</entry>
         <entry>::ffff:1.2.3.0/128</entry>
         <entry>::ffff:1.2.3.0/128</entry>
        </row>
       </tbody>
      </tgroup>
     </table>
   </sect2>

<!-- vs est couramment employé en français pour signaler une mise en
opposition de deux choses -->
   <sect2 id="datatype-inet-vs-cidr">
    <title><type>inet</type> vs <type>cidr</type></title>

    <para>
    La différence principale entre les types de données <type>inet</type>
    et <type>cidr</type> réside dans le fait que <type>inet</type> accepte des valeurs avec
    des bits non nuls à droite du masque de réseau, alors que <type>cidr</type>
    ne l'accepte pas.
    </para>

      <tip>
        <para>
         Les fonctions <function>host</function>, <function>text</function> et
	 <function>abbrev</function> permettent de modifier le format
	 d'affichage des valeurs <type>inet</type> et <type>cidr</type>.
        </para>
      </tip>
   </sect2>

   <sect2 id="datatype-macaddr">
    <title><type>macaddr</type></title>

    <indexterm>
     <primary>macaddr (type de données)</primary>
    </indexterm>

    <indexterm>
     <primary>adresse MAC</primary>
     <see>macaddr</see>
    </indexterm>

    <para>
     Le type <type>macaddr</type> stocke des adresses MAC, c'est-à-dire
     des adresses de cartes réseau Ethernet (mais les adresses MAC sont
     aussi utilisées dans d'autres cas). Les saisies sont acceptées dans
     de nombreux formats, dont&nbsp;:

     <simplelist>
      <member><literal>'08002b:010203'</literal></member>
      <member><literal>'08002b-010203'</literal></member>
      <member><literal>'0800.2b01.0203'</literal></member>
      <member><literal>'08-00-2b-01-02-03'</literal></member>
      <member><literal>'08:00:2b:01:02:03'</literal></member>
     </simplelist>

     qui indiquent tous la même adresse. Les majuscules et les minuscules sont
     acceptées pour les chiffres <literal>a</literal> à <literal>f</literal>.
     L'affichage se fait toujours selon le dernier format.
    </para>

   </sect2>

  </sect1>

  <sect1 id="datatype-bit">
   <title>Type chaîne de bits</title>

   <indexterm zone="datatype-bit">
    <primary>chaîne de bits</primary>
    <secondary>type de données</secondary>
   </indexterm>

   <para>
    Les chaînes de bits sont des chaînes de 0 et de 1. Elles peuvent être
    utilisées pour stocker ou visualiser des masques de bits.
    Il y a deux types bits en SQL&nbsp;:
    <type>bit(<replaceable>n</replaceable>)</type> et
    <type>bit varying(<replaceable>n</replaceable>)</type>, avec
    <replaceable>n</replaceable> un entier positif.
   </para>

   <para>
    Les données de type <type>bit</type> doivent avoir une longueur de 
    <replaceable>n</replaceable> bits exactement. Essayer de lui affecter une
    chaîne de bits plus longue ou plus courte déclenche une erreur.
    Les données de type <type>bit varying</type> ont une longueur variable,
    d'au maximum <replaceable>n</replaceable> bits&nbsp;;
    les chaînes plus longues sont rejetées.
    Écrire <type>bit</type> sans longueur est équivalent à 
    <literal>bit(1)</literal>, alors que <type>bit varying</type> sans
    longueur indique une taille illimitée.
   </para>

   <note>
    <para>
     Lors du transtypage explicite (cast) d'une chaîne de bits en
     champ de type <type>bit(<replaceable>n</replaceable>)</type>, la chaîne
     obtenue est complétée avec des zéros ou bien tronquée pour obtenir une
     taille de <replaceable>n</replaceable> bits exactement, sans que cela
     produise une erreur. De la même façon, si une chaîne de bits est
     explicitement transtypée en un champ de type
     <type>bit varying(<replaceable>n</replaceable>)</type>, elle est tronquée
     si sa longueur dépasse <replaceable>n</replaceable> bits.
    </para>
   </note>

   <para>
    Voir la <xref linkend="sql-syntax-bit-strings"/> pour plus d'information sur
    la syntaxe des constantes en chaîne de bits.
    Les opérateurs logiques et les fonctions de manipulation de chaînes
    sont décrits dans la <xref linkend="functions-bitstring"/>.
   </para>

   <example>
    <title>Utiliser les types de chaînes de bits</title>

<programlisting>CREATE TABLE test (a BIT(3), b BIT VARYING(5));
INSERT INTO test VALUES (B'101', B'00');
INSERT INTO test VALUES (B'10', B'101');
<computeroutput>
ERROR:  bit string length 2 does not match type bit(3)
</computeroutput>
INSERT INTO test VALUES (B'10'::bit(3), B'101');
SELECT * FROM test;
<computeroutput>
  a  |  b
-----+-----
 101 | 00
 100 | 101
</computeroutput></programlisting>
   </example>

   <para>
    Une valeur pour une chaîne de bit nécessite un octet pour chaque groupe de
    huit bits, plus cinq ou huit octets d'en-tête suivant la longueur de la
    chaîne (les valeurs longues peuvent être compressées ou déplacées, comme
    expliqué dans <xref linkend="datatype-character"/> pour les chaînes de
    caractères).
   </para>
  </sect1>

  <sect1 id="datatype-textsearch">
   <title>Types de recherche plein texte</title>

   <indexterm zone="datatype-textsearch">
    <primary>recherche plein texte</primary>
    <secondary>types de données</secondary>
   </indexterm>

   <indexterm zone="datatype-textsearch">
    <primary>recherche textuelle</primary>
    <secondary>types de données</secondary>
   </indexterm>

   <para>
    <productname>PostgreSQL</productname> fournit deux types de données conçus
    pour supporter la recherche plein texte qui est l'activité de recherche
    via une collection de <firstterm>documents</firstterm> en langage naturel
    pour situer ceux qui correspondent le mieux à une
    <firstterm>requête</firstterm>. Le type <type>tsvector</type> représente un
    document dans une forme convenant à une recherche plein texte alors que le
    type <type>tsquery</type> représente de façon similaire une requête.
    <xref linkend="textsearch"/> fournit une explication détaillée de cette
    capacité et <xref linkend="functions-textsearch"/> résumé les fonctions
    et opérateurs en relation.
   </para>

   <sect2 id="datatype-tsvector">
    <title><type>tsvector</type></title>

    <indexterm>
     <primary>tsvector (data type)</primary>
    </indexterm>

    <para>
     Une valeur <type>tsvector</type> est une liste triée de
     <firstterm>lexemes</firstterm> distincts, qui sont des mots qui ont été
     <firstterm>normalisés</firstterm> pour que différentes variantes du même
     mot apparaissent (voir <xref linkend="textsearch"/> pour plus de détails).
     Trier et éliminer les duplicats se font automatiquement lors des entrées,
     comme indiqué dans cet exemple&nbsp;:

<programlisting>
SELECT 'a fat cat sat on a mat and ate a fat rat'::tsvector;
                      tsvector
----------------------------------------------------
 'a' 'on' 'and' 'ate' 'cat' 'fat' 'mat' 'rat' 'sat'
</programlisting>

     (Comme le montre l'exemple, le tri se fait en premier sur la longueur
     puis alphabétiquement, mais ce détail n'est pas fréquemment important.)
     Pour représenter des lexemes contenant des espaces blancs ou des signes
	 de ponctuation, entourez-les avec des guillemets simples&nbsp;:

<programlisting>
SELECT $$the lexeme '    ' contains spaces$$::tsvector;
                 tsvector                  
-------------------------------------------
 'the' '    ' 'lexeme' 'spaces' 'contains'
</programlisting>

     (Nous utilisons les valeurs litérales entre guillemets simples dans cet
     exemple et dans le prochain pour éviter une confusion en ayant à doubler
     les guillemets à l'intérieur des valeurs litérales.) Les guillemets
     imbriqués et les antislashs doivent être doublés&nbsp;:

<programlisting>
SELECT $$the lexeme 'Joe''s' contains a quote$$::tsvector;
                    tsvector                    
------------------------------------------------
 'a' 'the' 'Joe''s' 'quote' 'lexeme' 'contains'
</programlisting>

     En option, les <firstterm>positions</firstterm> peuvent être attachées
     sur un ou plusieurs lexemes&nbsp;:

<programlisting>
SELECT 'a:1 fat:2 cat:3 sat:4 on:5 a:6 mat:7 and:8 ate:9 a:10 fat:11 rat:12'::tsvector;
                                  tsvector
-------------------------------------------------------------------------------
 'a':1,6,10 'on':5 'and':8 'ate':9 'cat':3 'fat':2,11 'mat':7 'rat':12 'sat':4
</programlisting>

     Une position indique normalement l'emplacement du mot source dans le
     document. Les informations de position sont utilisables pour avoir un
     <firstterm>score de proximité</firstterm>. Les valeurs des positions peuvent
     aller de 1 à 16383&nbsp;; les grands nombres sont limités silencieusement
     à 16383.
     Les positions dupliquée du même lexeme sont rejetées.
    </para>

    <para>
     Les lexemes qui ont des positions peuvent aussi avoir un label d'un
     certain <firstterm>poids</firstterm>. Les labels possibles sont
     <literal>A</literal>, <literal>B</literal>, <literal>C</literal> ou
     <literal>D</literal>.
     <literal>D</literal> est la valeur par défaut et n'est du coup pas affiché
     en sortie&nbsp;:

<programlisting>
SELECT 'a:1A fat:2B,4C cat:5D'::tsvector;
          tsvector          
----------------------------
 'a':1A 'cat':5 'fat':2B,4C
</programlisting>

     Les poids sont typiquement utilisés pour refléter la structure du
     document en marquant les mots du titre de façon différente des mots du
     corps. Les fonctions de score de la recherche plein texte peuvent assigner
     des priorités différentes aux marqueurs de poids différents.
    </para>

    <para>
     Il est important de comprendre que le type <type>tsvector</type> lui-même
     ne réalise aucune normalisation&nbsp;; il suppose que les mots qui lui sont
     fournis sont normalisés correctement pour l'application. Par exemple,

<programlisting>
select 'The Fat Rats'::tsvector;
      tsvector      
--------------------
 'Fat' 'The' 'Rats'
</programlisting>

     Pour la plupart des applications de recherche en anglais, les mots ci-dessus
     seraient considérés comme non normalisés mais <type>tsvector</type> n'y prête
     pas attention. Le texte des documents bruts doit habituellement passer via
     <function>to_tsvector</function> pour normaliser les mots de façon appropriée
     pour la recherche&nbsp;:

<programlisting>
SELECT to_tsvector('english', 'The Fat Rats');         
   to_tsvector   
-----------------
 'fat':2 'rat':3
</programlisting>

     De nouveau, voir <xref linkend="textsearch"/> pour plus de détails.
    </para>

   </sect2>

   <sect2 id="datatype-tsquery">
    <title><type>tsquery</type></title>

    <indexterm>
     <primary>tsquery (type de données)</primary>
    </indexterm>

    <para>
     Une valeur <type>tsquery</type> enregistre les lexemes qui doivent être
     recherchés et les combine en utilisant les opérateurs booléens
     <literal>&amp;</literal> (AND), <literal>|</literal> (OR) et
     <literal>!</literal> (NOT). Les parenthèses peuvent être utilisées pour
     forcer le regroupement des opérateurs&nbsp;:

<programlisting>
 SELECT 'fat &amp; rat'::tsquery;
    tsquery
---------------
 'fat' &amp; 'rat'

SELECT 'fat &amp; (rat | cat)'::tsquery;
          tsquery
---------------------------
 'fat' &amp; ( 'rat' | 'cat' )

SELECT 'fat &amp; rat &amp; ! cat'::tsquery;
        tsquery
------------------------
 'fat' &amp; 'rat' &amp; !'cat'
</programlisting>

     En l'absence de ces parenthèses, <literal>!</literal> (NOT) est lié plus
     fortement, et <literal>&amp;</literal> (AND) est lié plus
     fortement que <literal>|</literal> (OR).
    </para>

    <para>
     En option, les lexemes dans une <type>tsquery</type> peuvent être labelisés
     avec une lettre de poids ou plus, ce qui les restreint à une correspondance
     avec les seuls lexemes <type>tsvector</type> pour un de ces poids&nbsp;:

<programlisting>
SELECT 'fat:ab &amp; cat'::tsquery;
    tsquery
------------------
 'fat':AB &amp; 'cat'
</programlisting>
    </para>

    <para>
     Les règles de guillemets pour les lexemes sont identiques à celles décrites
     ci-dessus pour les lexemes de <type>tsvector</type>&nbsp;; et, comme avec
     <type>tsvector</type>, toute normalisation requise des mots doit se faire
     avant de les placer dans le type <type>tsquery</type>. La fonction
     <function>to_tsquery</function> est convenable pour réaliser une telle
     normalisation&nbsp;:

<programlisting>
SELECT to_tsquery('Fat:ab &amp; Cats');
    to_tsquery    
------------------
 'fat':AB &amp; 'cat'
</programlisting>
    </para>

   </sect2>

  </sect1>

  <sect1 id="datatype-uuid">
   <title>Type <acronym>UUID</acronym></title>

   <indexterm zone="datatype-uuid">
    <primary>UUID</primary>
   </indexterm>

   <para>
    Le type de données <type>uuid</type> stocke des identifiants universels
    uniques (<acronym>UUID</acronym>, acronyme de <foreignphrase>Universally
    Unique Identifiers</foreignphrase>) décrits dans les standards RFC 4122,
    ISO/IEC 9834-8:2005,
    et d'autres encore. (Certains systèmes font référence à ce type de données
    en tant qu'identifiant unique global (ou <acronym>GUID</acronym>
    <indexterm><primary>GUID</primary></indexterm>).) Un identifiant de ce type
    est une quantité sur 128 bits généré par un algorithme adéquat qui a peu
    de chances d'être reproduit par quelqu'un d'autre utilisant le même
    algorithme. Du coup, pour les systèmes distribués, ces identifiants
    fournissent une meilleure garantie d'unicité que ce que pourrait fournir
    une séquence, dont la valeur est unique seulement au sein d'une base
    de données.
   </para>

   <para>
    Un <acronym>UUID</acronym> est écrit comme une séquence de chiffres
    hexadécimaux en minuscule, répartis en différents groupes séparés par
    un tiret. Plus précisément, il s'agit d'un groupe de huit chiffres
    suivis de trois groupes de quatre chiffres terminés par un groupe de
    douze chiffres, ce qui fait un total de 32 chiffres représentant les
    128 bits. Voici un exemple d'<acronym>UUID</acronym> dans sa forme
    standard&nbsp;:
<programlisting>
a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11
</programlisting>
    PostgreSQL accepte aussi d'autres formes en entrée&nbsp;: utilisation
    des majuscules, de crochets englobant le nombre, suppression des tirets.
    Voici quelques exemples&nbsp;:
<programlisting>
A0EEBC99-9C0B-4EF8-BB6D-6BB9BD380A11
{a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11}
a0eebc999c0b4ef8bb6d6bb9bd380a11
</programlisting>
    L'affichage est toujours dans la forme standard.
   </para>

   <para>
    Pour générer des <acronym>UUID</acronym>, le module contrib
    <literal>uuid-ossp</literal> fournit des fonctions qui implémentent
    les algorithmes standards. Sinon, les <acronym>UUID</acronym>
    peuvent être générés par des applications clientes ou par d'autres
    bibliothèques appelées par une fonction serveur.
   </para>
  </sect1>

  <sect1 id="datatype-xml">
   <title>Type <acronym>XML</acronym></title>

   <indexterm zone="datatype-xml">
    <primary>XML</primary>
   </indexterm>

   <para>
    Le type de données <type>xml</type> est utilisé pour stocker des données
    au format XML. Son avantage sur un champ de type <type>text</type> est
    qu'il vérifie que les valeurs sont bien formées. De plus, il existe de
    nombreuses fonctions pour réaliser des opérations de vérification à partir
    de ce type&nbsp;; voir la <xref linkend="functions-xml"/>. L'utilisation
    de ce type de données requiert que l'étape de compilation a utilisé
    l'option <option>--with-libxml</option>.
   </para>

   <para>
    Le type <type>xml</type> peut stocker des <quote>documents</quote> bien
    formés, suivant la définition du standard XML, ainsi que des fragments
    de contenu (<quote>content</quote>), qui sont définis par
    <literal>XMLDecl? content</literal> du standard XML. Cela signifie
    que les fragments de contenu peuvent avoir plus d'un élément racine ou
    n&oelig;ud caractère. L'expression
    <literal><replaceable>valeurxml</replaceable> IS DOCUMENT</literal>
    permet d'évaluer si une valeur <type>xml</type> particulière
    est un document complet ou seulement un fragment de contenu.
   </para>

   <sect2>
    <title>Créer des valeurs XML</title>
   <para>
    Pour produire une valeur de type <type>xml</type> à partir d'une donnée de
    type caractère, utilisez la fonction <function>xmlparse</function>&nbsp;:
    <indexterm><primary>xmlparse</primary></indexterm>
<synopsis>
XMLPARSE ( { DOCUMENT | CONTENT } <replaceable>valeur</replaceable>)
</synopsis>
    Quelques exemples&nbsp;:
<programlisting><![CDATA[
XMLPARSE (DOCUMENT '<?xml version="1.0"?><book><title>Manual</title><chapter>...</chapter></book>')
XMLPARSE (CONTENT 'abc<foo>bar</foo><bar>foo</bar>')
]]></programlisting>
    Bien que cela soit la seule façon de convertir des chaînes de
    caractère en valeurs XML d'après le standard XML, voici des syntaxes
    spécifiques à PostgreSQL&nbsp;:
<programlisting><![CDATA[
xml '<foo>bar</foo>'
'<foo>bar</foo>'::xml
]]></programlisting>
   </para>

   <para>
    Le type <type>xml</type> ne valide pas les valeurs en entrée par rapport
    à une déclaration de type de document inclue 
    (DTD).<indexterm><primary>DTD</primary></indexterm>
   </para>

   <para>
    L'opération inverse, produisant une chaîne de caractères à partir d'une
    valeur au type <type>xml</type>, utilise la fonction
    <function>xmlserialize</function>:<indexterm><primary>xmlserialize</primary></indexterm>
<synopsis>
XMLSERIALIZE ( { DOCUMENT | CONTENT } <replaceable>value</replaceable> AS <replaceable>type</replaceable> )
</synopsis>
    <replaceable>type</replaceable> peut être
    <type>character</type>, <type>character varying</type> ou
    <type>text</type> (ou un alias de ces derniers). Encore une fois, d'après
    le standard SQL, c'est le seul moyen de convertir le type
    <type>xml</type> vers les types caractère mais PostgreSQL autorise aussi
    la conversion simple de la valeur.
   </para>

   <para>
    Lorsque les valeurs des chaînes de caractère sont converties vers ou à
    partir du type <type>xml</type> sans passer par <type>XMLPARSE</type> ou
    <type>XMLSERIALIZE</type>, respectivement, le choix de
    <literal>DOCUMENT</literal> ou de <literal>CONTENT</literal> est
    déterminé par un paramètre de configuration niveau session,
    <quote>XML OPTION</quote>
    <indexterm><primary>XML OPTION</primary></indexterm>, qui peut être
    configuré par la commande habituelle&nbsp;:
<synopsis>
SET XML OPTION { DOCUMENT | CONTENT };
</synopsis>
    ou la syntaxe PostgreSQL&nbsp;:
<synopsis>
SET xmloption TO { DOCUMENT | CONTENT };
</synopsis>
    La valeur par défaut est <literal>CONTENT</literal>, donc toutes les formes
    de données XML sont autorisées.
   </para>
   </sect2>

   <sect2>
    <title>Gestion de l'encodage</title>
   <para>
    Une grande attention doit prévaloir lors de la gestion de plusieurs
    encodages sur le client, le serveur ou dans les données XML qui
    passent entre eux. Lors de l'utilisation du mode texte pour passer
    les requêtes au serveur et pour renvoyer les résultats au client
    (qui se trouve dans le mode normal), PostgreSQL convertit toutes les
    données de type caractère passées entre le client et le serveur et
    vice-versa suivant l'encodage spécifique du bout final&nbsp;; voir la
    <xref linkend="multibyte"/>. Ceci inclut les représentations textuelles
    des valeurs XML, comme dans les exemples ci-dessus. Ceci signifie
    que les déclarations d'encodage contenues dans les données XML pourraient
    devenir invalide lorsque les données sont converties vers un autre
    encodage lors du transfert entre le client et le serveur, alors que la
    déclaration de l'encodage n'est pas modifiée. Pour s'en sortir, une
    déclaration d'encodage contenue dans une chaîne de caractères
    présentée en entrée du type <type>xml</type> est
    <emphasis>ignorée</emphasis>, et le contenu est toujours supposé être de
    l'encodage du serveur. En conséquence, pour un traitement correct,
    ces chaînes de caractères de données XML doivent être envoyées du client
    dans le bon encodage. C'est de la responsabilité du client de soit
    convertir le document avec le bon encodage client avant de l'envoyer au
    serveur soit d'ajuster l'encodage client de façon appropriée. En sortie,
    les valeurs du type <type>xml</type> n'auront pas une déclaration
    d'encodage et les clients devront supposer que les données sont dans
    l'encodage du client.
   </para>

   <para>
    Lors de l'utilisation du mode binaire pour le passage des paramètres
    de la requête au serveur et des résultats au client, aucune conversion
    de jeu de caractères n'est réalisée, donc la situation est différente.
    Dans ce cas, une déclaration d'encodage dans les données XML sera observée
    et, si elle est absente, les données seront supposées être en UTF-8 (comme
    requis par le standard XML&nbsp;; notez que PostgreSQL ne supporte pas
    du tout UTF-16). En sortie, les données auront une déclaration d'encodage
    spécifiant l'encodage client sauf si l'encodage client est UTF-8, auquel
    case elle sera omise.
   </para>

   <para>
    Le traitement des données XML avec PostgreSQL sera moins complexe et plus
    efficace si l'encodage des données, l'encodage client et serveur sont
    identiques. Comme les données XML sont traitées en interne en UTF-8, les
    traitements seront plus efficaces si l'encodage serveur est aussi en
    UTF-8.
   </para>
   </sect2>

   <sect2>
   <title>Accéder aux valeurs XML</title>

   <para>
    Le type de données <type>xml</type> est inhabituel dans le sens où il ne
    dispose pas d'opérateurs de comparaison. Ceci est dû au fait qu'il n'existe
    pas d'algorithme de comparaison bien défini et utile pour des données XML.
    Une conséquence de ceci est que vous ne pouvez pas récupérer des lignes en
    comparant une colonne <type>xml</type> avec une valeur de recherche. Les
    valeurs XML doivent du coup être typiquement accompagnées par un champ
    clé séparé comme un identifiant. Une autre solution pour la comparaison
    de valeurs XML est de les convertir en des chaînes de caractères, mais
    notez que la comparaison de chaînes n'a que peu à voir avec une
    méthode de comparaison XML utile.
   </para>

   <para>
    Comme il n'y a pas d'opérateurs de comparaison pour le type de données
    <type>xml</type>, il n'est pas possible de créer un index directement
    sur une colonne de ce type. Si une recherche rapide est souhaitée dans
    des données XML, il est toujours possible de convertir l'expression en
    une chaîne de caractères et d'indexer cette conversion. Il est aussi
    possible d'indexer une expression XPath. La vraie requête devra bien sûr
    être ajustée à une recherche sur l'expression indexée.
   </para>

   <para>
    La fonctionnalité de recherche plein texte peut aussi être utilisée pour
    accélérer les recherches dans des données XML. Le support du pré-traitement
    nécessaire n'est cependant pas disponible dans la distribution PostgreSQL.
   </para>
   </sect2>
  </sect1>

  &array;

  &rowtypes;

  <sect1 id="datatype-oid">
   <title>Types identifiant d'objet</title>

   <indexterm zone="datatype-oid">
    <primary>identifiant d'objet</primary>
    <secondary>type de données</secondary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>oid</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regproc</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regprocedure</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regoper</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regoperator</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regclass</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regtype</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regconfig</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>regdictionary</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>xid</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>cid</primary>
   </indexterm>

   <indexterm zone="datatype-oid">
    <primary>tid</primary>
   </indexterm>

   <para>
    Les identifiants d'objets (OID) sont utilisés en interne par
    <productname>PostgreSQL</productname> comme clés primaires de
    différentes tables système. Les OID ne sont pas ajoutés aux tables
    utilisateur à moins que <literal>WITH OIDS</literal> ne soit indiqué
    lors de la création de la table ou que la variable de configuration
    <xref linkend="guc-default-with-oids"/> ne soit activée. Le type <type>oid</type>
    représente un identifiant d'objet. Il existe également différents types
    alias du type <type>oid</type>&nbsp;: <type>regproc</type>, <type>regprocedure</type>,
    <type>regoper</type>, <type>regoperator</type>, <type>regclass</type>,
    <type>regtype</type>, <type>regconfig</type> et <type>regdictionary</type>.
    Le <xref linkend="datatype-oid-table"/> en donne un aperçu.
   </para>

   <para>
    Le type <type>oid</type> est à ce jour un entier non-signé sur quatre octets.
    Il n'est, de ce fait, pas suffisamment large pour garantir l'unicité au
    sein d'une base de données volumineuse, voire même au sein d'une très
    grosse table. Il est donc déconseillé d'utiliser une colonne OID comme clé
    primaire d'une table utilisateur. Les OID sont avant-tout destinés à
    stocker des références vers les tables système.
   </para>

   <para>
    Le type <type>oid</type> lui-même dispose de peu d'opérations en dehors de la
    comparaison. Il peut toutefois être converti en entier (integer)
    et manipulé par les opérateurs habituels des entiers
    (attention aux possibles confusions entre les entiers signés et non
    signés dans ce cas).
   </para>

   <para>
    Les types alias d'OID ne disposent pas d'opérations propres à
    l'exception des routines spécialisées de saisie et d'affichage.
    Ces routines acceptent et affichent les noms symboliques des objets systèmes,
    plutôt que la valeur numérique brute que le type <type>oid</type>
    utilise. Les types alias permettent de simplifier la recherche des
    valeurs OID des objets. Par exemple, pour examiner les lignes
    <structname>pg_attribute</structname> en relation avec une table 
    <literal>ma_table</literal>, on peut écrire&nbsp;:
<programlisting>SELECT * FROM pg_attribute WHERE attrelid = 'ma_table'::regclass;</programlisting>
    plutôt que&nbsp;:
<programlisting>SELECT * FROM pg_attribute
WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'ma_table');</programlisting>
    Bien que cela semble une bonne solution, c'est un peu trop simplifié.
    Un sous-select bien plus compliqué peut être nécessaire pour sélectionner
    le bon OID s'il existe plusieurs tables nommées <literal>ma_table</literal> dans
    différents schémas. Le convertisseur de saisie <type>regclass</type> gère la
    recherche de la table en fonction du paramétrage du parcours des schémas et
    effectue donc la <quote>bonne recherche</quote> automatiquement. De façon
    similaire, la conversion d'un OID de table en <type>regclass</type>
    pour l'affichage d'un OID numérique est aisée.
   </para>

    <table id="datatype-oid-table">
     <title>Types identifiant d'objet</title>
     <tgroup cols="4">
      <colspec colnum="1" colwidth="0.7*"/>
      <colspec colnum="2" colwidth="0.7*"/>
      <colspec colnum="3" colwidth="1.3*"/>
      <colspec colnum="4" colwidth="1.3*"/>
      <thead>
       <row>
        <entry>Nom</entry>
        <entry>Référence</entry>
        <entry>Description</entry>
        <entry>Exemple</entry>
       </row>
      </thead>

      <tbody>

       <row>
        <entry><type>oid</type></entry>
        <entry>tous</entry>
        <entry>identifiant d'objet numérique</entry>
        <entry><literal>564182</literal></entry>
       </row>

       <row>
        <entry><type>regproc</type></entry>
        <entry><structname>pg_proc</structname></entry>
        <entry>nom de fonction</entry>
        <entry><literal>sum</literal></entry>
       </row>

       <row>
        <entry><type>regprocedure</type></entry>
        <entry><structname>pg_proc</structname></entry>
        <entry>fonction avec types d'arguments</entry>
        <entry><literal>sum(int4)</literal></entry>
       </row>

       <row>
        <entry><type>regoper</type></entry>
        <entry><structname>pg_operator</structname></entry>
        <entry>nom d'opérateur</entry>
        <entry><literal>+</literal></entry>
       </row>

       <row>
        <entry><type>regoperator</type></entry>
        <entry><structname>pg_operator</structname></entry>
        <entry>opérateur avec types d'arguments</entry>
        <entry><literal>*(integer,integer)</literal> ou <literal>-(NONE,integer)</literal></entry>
       </row>

       <row>
        <entry><type>regclass</type></entry>
        <entry><structname>pg_class</structname></entry>
        <entry>nom de relation</entry>
        <entry><literal>pg_type</literal></entry>
       </row>

       <row>
        <entry><type>regtype</type></entry>
        <entry><structname>pg_type</structname></entry>
        <entry>nom de type de données</entry>
        <entry><literal>integer</literal></entry>
       </row>

       <row>
        <entry><type>regconfig</type></entry>
        <entry><structname>pg_ts_config</structname></entry>
        <entry>configuration de la recherche plein texte</entry>
        <entry><literal>english</literal></entry>
       </row>

       <row>
        <entry><type>regdictionary</type></entry>
        <entry><structname>pg_ts_dict</structname></entry>
	<entry>dictionnaire de la recherche plein texte</entry>
        <entry><literal>simple</literal></entry>
       </row>
      </tbody>
     </tgroup>
    </table>

   <para>
    Tous les types alias d'OID acceptent des noms qualifiés par le schéma,
    et affichent des noms préfixés par un schéma si l'objet ne peut être 
    trouvé dans le chemin de recherche courant sans être qualifié.
    Les types alias <type>regproc</type> et <type>regoper</type> n'acceptent que des
    noms uniques en entrée (sans surcharge), si bien qu'ils sont d'un usage
    limité&nbsp;; dans la plupart des cas, <type>regprocedure</type> et
    <type>regoperator</type> sont plus appropriés. Pour <type>regoperator</type>,
    les opérateurs unaires sont identifiés en écrivant <literal>NONE</literal> pour
    les opérandes non utilisés.
   </para>

   <para>
    Une propriété supplémentaire des types alias d'OID est que, si une
    constante d'un de ces types apparaît dans une expression stockée
    (telle que l'expression par défaut d'une colonne ou une vue), elle crée une
    dépendance sur l'objet référencé. Par exemple, si une colonne a une
    expression par défaut <literal>nextval('ma_seq'::regclass)</literal>,
    <productname>PostgreSQL</productname> comprend que l'expression par
    défaut dépend de la séquence <literal>ma_seq</literal>&nbsp;; le système ne
    permet alors pas la suppression de la séquence si l'expression par
    défaut n'est pas elle-même supprimée au préalable.
   </para>

   <para>
    Un autre type d'identifiant utilisé par le système est <type>xid</type>, ou
    identifiant de transaction (abrégée <abbrev>xact</abbrev>).
    C'est le type de données des colonnes système <structfield>xmin</structfield> et
    <structfield>xmax</structfield>. Les identifiants de transactions sont
    stockés sur 32 bits.
   </para>

   <para>
    Un troisième type d'identifiant utilisé par le système est <type>cid</type>,
    ou identifiant de commande. C'est le type de données des colonnes systèmes
    <structfield>cmin</structfield> et <structfield>cmax</structfield>.
    Les identifiants de commandes sont aussi stockés sur 32 bits.
   </para>

   <para>
    Le dernier type d'identifiant utilisé par le système est <type>tid</type>,
    ou identifiant de ligne (tuple). C'est le type de données
    des colonnes système <structfield>ctid</structfield>. Un identifiant de tuple
    est une paire (numéro de bloc, index de tuple dans le bloc) qui identifie l'emplacement
    physique de la ligne dans sa table.
   </para>

   <para>
    Les colonnes systèmes sont expliquées plus en détail dans la
    <xref linkend="ddl-system-columns"/>.
   </para>
  </sect1>

  <sect1 id="datatype-pseudo">
   <title>Pseudo-Types</title>

   <indexterm zone="datatype-pseudo">
    <primary>record</primary>
   </indexterm>

   <indexterm zone="datatype-pseudo">
    <primary>any</primary>
   </indexterm>

   <indexterm zone="datatype-pseudo">
    <primary>anyelement</primary>
   </indexterm>

   <indexterm zone="datatype-pseudo">
    <primary>anyarray</primary>
   </indexterm>

   <indexterm zone="datatype-pseudo">
    <primary>anynonarray</primary>
   </indexterm>

   <indexterm zone="datatype-pseudo">
    <primary>anyenum</primary>
   </indexterm>

   <indexterm zone="datatype-pseudo">
    <primary>void</primary>
   </indexterm>

   <indexterm zone="datatype-pseudo">
    <primary>trigger</primary>
   </indexterm>

   <indexterm zone="datatype-pseudo">
    <primary>language_handler</primary>
   </indexterm>

   <indexterm zone="datatype-pseudo">
    <primary>cstring</primary>
   </indexterm>

   <indexterm zone="datatype-pseudo">
    <primary>internal</primary>
   </indexterm>

   <indexterm zone="datatype-pseudo">
    <primary>opaque</primary>
   </indexterm>

   <para>
    Le système de types de <productname>PostgreSQL</productname>
    contient un certain nombre de types à usage spécial qui sont
    collectivement appelés des <firstterm>pseudo-types</firstterm>. Un
    pseudo-type ne peut être utilisé comme type d'une colonne de table, mais peut
    l'être pour déclarer un argument de fonction ou un type 
    de résultat. Tous les pseudo-types disponibles sont utiles dans des
    situations où une fonction ne se contente pas d'accepter et retourner
    des valeurs d'un type de données <acronym>SQL</acronym> particulier. Le
    <xref linkend="datatype-pseudotypes-table"/> liste les différents pseudo-types.
   </para>

    <table id="datatype-pseudotypes-table">
     <title>Pseudo-Types</title>
     <tgroup cols="2">
      <colspec colnum="1" colwidth="1*"/>
      <colspec colnum="2" colwidth="5.5*"/>
      <thead>
       <row>
        <entry>Nom</entry>
        <entry>Description</entry>
       </row>
      </thead>

      <tbody>
       <row>
        <entry><type>any</type></entry>
        <entry>
         Indique qu'une fonction accepte tout type de données,
         quel qu'il soit.
        </entry>
       </row>

       <row>
        <entry><type>anyarray</type></entry>
        <entry>
         Indique qu'une fonction accepte tout type tableau (voir la
         <xref linkend="extend-types-polymorphic"/>).
        </entry>
       </row>

       <row>
        <entry><type>anyelement</type></entry>
        <entry>Indique qu'une fonction accepte tout type de données
        (voir la <xref linkend="extend-types-polymorphic"/>).</entry>
       </row>

       <row>
        <entry><type>anyenum</type></entry>
        <entry>Indique que la fonction accepte tout type de données enum
        (voir <xref linkend="extend-types-polymorphic"/> et
        <xref linkend="datatype-enum"/>).</entry>
       </row>

       <row>
        <entry><type>anynonarray</type></entry>
	<entry>Indique que la fonction accepte tout type de données non-array
        (voir <xref linkend="extend-types-polymorphic"/>).</entry>
       </row>

       <row>
        <entry><type>cstring</type></entry>
        <entry>Indique qu'une fonction accepte ou retourne une chaîne de caractères
         C (terminée par un NULL).</entry>
       </row>

       <row>
        <entry><type>internal</type></entry>
        <entry>Indique qu'une fonction accepte ou retourne un type de données
         interne du serveur de bases de données.</entry>
       </row>

       <row>
        <entry><type>language_handler</type></entry>
        <entry>Une fonction d'appel de langage procédural est déclarée retourner
	 un <type>language_handler</type>.</entry>
       </row>

       <row>
        <entry><type>record</type></entry>
        <entry>Identifie une fonction qui retourne un type de ligne non spécifié.</entry>
       </row>

       <row>
        <entry><type>trigger</type></entry>
        <entry>Une fonction déclencheur est déclarée comme retournant un type
	 <type>trigger</type>.</entry>
       </row>

       <row>
        <entry><type>void</type></entry>
        <entry>Indique qu'une fonction ne retourne aucune valeur.</entry>
       </row>

       <row>
        <entry><type>opaque</type></entry>
        <entry>Un type de données obsolète qui servait précédemment à tous les
	 usages cités ci-dessus.</entry>
       </row>
      </tbody>
     </tgroup>
    </table>

   <para>
    Les fonctions codées en C (incluses ou chargées dynamiquement)
    peuvent être déclarées comme acceptant ou retournant tout pseudo-type. Il est de
    la responsabilité de l'auteur de la fonction de s'assurer du bon comportement
    de la fonction lorsqu'un pseudo-type est utilisé comme type d'argument.
   </para>

   <para>
    Les fonctions codées en langage procédural ne peuvent utiliser les
    pseudo-types que dans les limites imposées par l'implantation du langage.
    À ce jour, tous les langages procéduraux
    interdisent l'usage d'un pseudo-type comme argument et n'autorisent que
    <type>void</type> et <type>record</type> comme type de retours (plus <type>trigger</type>
    lorsque la fonction est utilisée comme déclencheur).
    Certains supportent également les fonctions polymorphes qui utilisent les 
    types <type>anyarray</type>, <type>anyelement</type>, <type>anyenum</type>,
    <type>anynonarray</type>.
   </para>

   <para>
    Le pseudo-type <type>internal</type> sert à déclarer des fonctions qui
    ne sont appelées que par le système en interne,
    et non pas directement par une requête <acronym>SQL</acronym>.
    Si une fonction accepte au minimum un argument de type <type>internal</type>,
    alors elle ne peut être appelée depuis <acronym>SQL</acronym>.
    Pour préserver la sécurité du type de cette restriction, il est important de
    suivre la règle de codage suivante&nbsp;: ne jamais créer de fonction qui retourne un
    <type>internal</type> si elle n'accepte pas au moins un argument de type
    <type>internal</type>.
   </para>

  </sect1>

 </chapter>