Changeset 769

Show
Ignore:
Timestamp:
10/24/07 23:47:02 (1 year ago)
Author:
gleu
Message:

Nouvelles traductions du jour (8.3b1).

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/manuel/maintenance.xml

    r735 r769  
    9999 
    100100  <para> 
    101    Fortunately, autovacuum (<xref linkend="autovacuum"/>) monitors table 
    102    activity and performs <command>VACUUM</command>s when necessary. 
    103    Autovacuum works dynamically so it is often better 
    104    administration-scheduled vacuuming. 
     101   Heureusement, l'autovacuum (<xref linkend="autovacuum"/>) surveille 
     102   l'activité des tables et exécute des <command>VACUUM</command> si 
     103   nécessaire. L'autovacuum fonctionne dynamiquement donc il est souvent 
     104   meilleur que des opérations de VACUUM programmées.. 
    105105  </para> 
    106106 
    …… 
    144144   un algorithme plus agressif pour récupérer l'espace consommé par les versions 
    145145   mortes des lignes. Tout espace qui est libéré par <command>VACUUM 
    146    FULL</command> est immédiatement rendu au système d'exploitation and the 
    147    table data is physically compacted on the disk. Malheureusement, 
     146   FULL</command> est immédiatement rendu au système d'exploitation et les 
     147   données de la table sont compressées sur le disque. Malheureusement, 
    148148   cette variante de la commande <command>VACUUM</command> acquiert un verrou 
    149149   exclusif sur chaque table avant que <command>VACUUM FULL</command> ne la 
    …… 
    165165 
    166166   <para> 
    167     Fortunately, autovacuum (<xref linkend="autovacuum"/>) monitors table 
    168     activity and performs <command>VACUUM</command>s when necessary.  This 
    169     eliminates the need for administrators to worry about disk space 
    170     recovery in all but the most unusual cases. 
    171    </para> 
    172  
    173    <para> 
    174     For administrators who want to control <command>VACUUM</command> 
    175     themselves, the standard form of <command>VACUUM</command> is best used to 
    176     maintain a steady-state usage of disk space. If you need to return 
    177     disk space to the operating system, you can use <command>VACUUM 
    178     FULL</command>, but this is unwise if the table will just grow again in the 
    179     future.  Moderately-frequent standard <command>VACUUM</command> runs are a 
    180     better approach than infrequent <command>VACUUM FULL</command> runs for 
    181     maintaining heavily-updated tables.  However, if some heavily-updated 
    182     tables have gone too long with infrequent <command>VACUUM</command>, you can 
    183     use <command>VACUUM FULL</command> or <command>CLUSTER</command> to get performance 
    184     back (it is much slower to scan a table containing almost only dead 
    185     rows). 
    186    </para> 
    187  
    188    <para> 
    189     For those not using autovacuum, one approach is to schedule a 
    190     database-wide <command>VACUUM</command> once a day during low-usage period, 
    191     supplemented by more frequent vacuuming of heavily-updated tables if 
    192     necessary. (Some installations with extremely high update rates vacuum 
    193     their busiest tables as often as once every few minutes.) If you have 
    194     multiple databases in a cluster, don't forget to 
    195     <command>VACUUM</command> each one; the program <xref 
    196     linkend="app-vacuumdb" endterm="app-vacuumdb-title"/> might be helpful. 
     167    Heureusement, l'autovacuum (<xref linkend="autovacuum"/>) surveille 
     168    l'activité des tables et exécute des opérations <command>VACUUM</command> 
     169    si nécessaire. Ceci élimine le besoin pour les administrateurs de 
     170    s'inquiéter pour récupération de la place disque dans la plupart des cas. 
     171   </para> 
     172 
     173   <para> 
     174    Pour les administrateurs qui veulent contrôler <command>VACUUM</command> 
     175    eux-mêmes, la forme standard du <command>VACUUM</command> est mieux 
     176    utilisée pour maintenir une bonne utilisation de l'espace disque. Si vous 
     177    avez besoin de récupérer l'espace disque, vous pouvez utiliser  
     178    <command>VACUUM FULL</command> mais c'est déconseillé si la table va 
     179    grossir de nouveau dans le futur. Des exécutions modérément fréquentes 
     180    du <command>VACUUM</command> standard sont une meilleure approche que des 
     181    <command>VACUUM FULL</command> occasionnels pour maintenir des tables 
     182    fréquemment mises à jour. Néanmoins, si des tables fréquemment mises à 
     183    jour n'ont pas eu de <command>VACUUM</command> fréquent, vous pouvez 
     184    utiliser <command>VACUUM FULL</command> ou <command>CLUSTER</command> 
     185    pour obtenir de nouveau de bonnes performances (il est bien plus lent 
     186    de parcourir une table contenant une grosse majorité de lignes mortes). 
     187   </para> 
     188 
     189   <para> 
     190    Pour ceux qui n'utilisent pas autovacuum, une approche alternative est de 
     191    planifier un <command>VACUUM</command> sur la base complète une fois 
     192    par jour lorsque l'utilisation n'est pas grande, avec en plus des 
     193    opérations de <command>VACUUM</command> plus fréquentes pour les tables 
     194    très impactées par des mises à jour, si nécessaire. 
     195    (Certaines installations avec énormément de mises à jour peuvent exécuter 
     196    des VACUUM toutes les quelques minutes.) Si vous avez plusieurs bases dans 
     197    un cluster, n'oubliez pas d'exécuter un <command>VACUUM</command> sur 
     198    chacune d'elles&nbsp;; le programme <xref 
     199    linkend="app-vacuumdb" endterm="app-vacuumdb-title"/> pourrait être utile. 
    197200   </para> 
    198201 
    …… 
    277280 
    278281   <para> 
    279     Fortunately, autovacuum (<xref linkend="autovacuum"/>) monitors table 
    280     activity and performs <command>ANALYZE</command>s when necessary.  This 
    281     eliminates the need for administrators to manually schedule 
    282     <command>ANALYZE</command>. 
    283    </para> 
    284  
    285    <para> 
    286     For those not using autovacuum, one approach is to schedule a 
    287     database-wide <command>ANALYZE</command> once a day at a low-usage time of 
    288     day; this can usefully be combined with a nightly <command>VACUUM</command>. 
    289     However, sites with relatively slowly changing table statistics might 
    290     find that this is overkill, and that less-frequent <command>ANALYZE</command> 
    291     runs are sufficient. 
     282    Heureusement, l'autovacuum (<xref linkend="autovacuum"/>) surveille 
     283    l'activité des tables et exécute des opérations <command>ANALYZE</command> 
     284    si nécessaire. Ceci élimine le besoin pour les administrateurs de 
     285    planifier manuellement ces opérations. 
     286   </para> 
     287 
     288   <para> 
     289    Pour ceux qui n'utilisent pas l'autovacuum, une approche alternative 
     290    serait de planifier un <command>ANALYZE</command> sur la base complète 
     291    au moins une fois par jour&nbsp;; cela peut être combiné avec un 
     292    <command>VACUUM</command> le soir. Néanmoins, les sites avec relativement 
     293    peu de modifications dans les statistiques de table peuvent trouver cela 
     294    trop et peut-être que des <command>ANALYZE</command> moins fréquents 
     295    seraient suffisants. 
    292296   </para> 
    293297  </sect2> 
    …… 
    488492    pas être utilisé sauf si <xref linkend="guc-track-counts"/> est configuré 
    489493    à <literal>true</literal>. 
    490     In the default configuration, autovacuuming is enabled and the related 
    491     configuration parameters are appropriately set. 
    492    </para> 
    493  
    494    <para> 
    495     Beginning in <productname>PostgreSQL</productname> 8.3, autovacuum has a 
    496     multi-process architecture: there is a daemon process, called the 
    497     <firstterm>autovacuum launcher</firstterm>, which is in charge of starting 
    498     an <firstterm>autovacuum worker</firstterm> process on each database every 
    499     <xref linkend="guc-autovacuum-naptime"/> seconds. On each run, the worker 
    500     process checks each table within that database, and <command>VACUUM</command> or 
    501     <command>ANALYZE</command> commands are issued as needed. 
    502    </para> 
    503  
    504    <para> 
    505     The <xref linkend="guc-autovacuum-max-workers"/> setting limits how many 
    506     workers may be running at any time. If several large tables all become 
    507     eligible for vacuuming in a short amount of time, all autovacuum workers 
    508     may end up vacuuming those tables for a very long time. This would result 
    509     in other tables and databases not being vacuumed until a worker became 
    510     available. There is not a limit on how many workers might be in a 
    511     single database, but workers do try to avoid repeating work that has 
    512     already been done by other workers. Note that the number of running 
    513     workers does not count towards the <xref linkend="guc-max-connections"/> nor 
    514     the <xref linkend="guc-superuser-reserved-connections"/> limits. 
     494    Dans la configuration par défaut, l'autovacuum est activé et les 
     495    paramètres liés sont correctement configurés. 
     496   </para> 
     497 
     498   <para> 
     499    À partir de <productname>PostgreSQL</productname> 8.3, l'autovacuum a 
     500    une architecture multi-processus&nbsp;: il y a un processus démon appelé 
     501    le lanceur d'autovacuum (<firstterm>autovacuum launcher</firstterm>), qui 
     502    est en charge de lancer un processus travailleur (<firstterm>autovacuum worker</firstterm>) pour chaque base de données toutes les 
     503    <xref linkend="guc-autovacuum-naptime"/> secondes. À chaque tour, le 
     504    travailleur vérifie chaque table dans la base et les commandes <command>VACUUM</command> ou <command>ANALYZE</command> sont exécutées 
     505    si nécessaire. 
     506   </para> 
     507 
     508   <para> 
     509    Le paramètre <xref linkend="guc-autovacuum-max-workers"/> limite le 
     510    nombre maximum de travailleurs pouvant être lancés à tout moment. Si 
     511    plusieurs grosses tables deviennent toutes éligibles pour un VACUUM dans 
     512    un court espace de table, tous les travailleurs de l'autovacuum pourraient 
     513    ne s'occuper que de ces tables pour un très long moment. Ceci aurait pour 
     514    conséquences que les autres tables et bases ne seraient plus l'objet 
     515    d'opérations de VACUUM jusqu'à la disponibilité d'un travailleur. Il 
     516    n'y a pas de limite au nombre de travailleurs sur une seule base mais 
     517    les travailleurs tentent d'éviter de répéter le travail qui a déjà été 
     518    réalisé par d'autres travailleurs. Notez que le nombre de travailleurs 
     519    en cours d'exécution ne comptent pas dans les limites <xref 
     520    linkend="guc-max-connections"/> et <xref 
     521    linkend="guc-superuser-reserved-connections"/>. 
    515522   </para> 
    516523 
    …… 
    604611 
    605612   <para> 
    606     When multiple workers are running, the cost limit is 
    607     <quote>balanced</quote> among all the running workers, so that the 
    608     total impact on the system is the same, regardless of the number 
    609     of workers actually running. 
     613    Lorsque plusieurs processus autovacuum sont en cours d'exécution, la 
     614    limite de coût est <quote>répartie</quote> parmi tous les processus pour 
     615    que l'impact total sur le système soit identique quelque soit le nombre 
     616    de processus en cours d'exécution. 
    610617   </para> 
    611618  </sect2> 
    …… 
    696703 
    697704  <para> 
    698    Une meilleure approche est d'envoyer la sortie <systemitem>stderr</systemitem> 
    699    du serveur dans un programme de rotation de journaux. Il 
    700    existe un programme interne de rotation que vous pouvez utiliser en 
    701    configurant le paramètre <literal>logging_collector</literal> à 
    702    <literal>true</literal> dans <filename>postgresql.conf</filename>. Les paramètres de 
    703    contrôle pour ce programme sont décrits dans <xref 
    704    linkend="runtime-config-logging-where"/>. You can also use this approach 
    705    to capture the log data in machine readable CSV format. 
     705   Une meilleure approche est d'envoyer la sortie 
     706   <systemitem>stderr</systemitem> du serveur dans un programme de rotation de 
     707   journaux. Il existe un programme interne de rotation que vous pouvez 
     708   utiliser en configurant le paramètre <literal>logging_collector</literal> à 
     709   <literal>true</literal> dans <filename>postgresql.conf</filename>. Les 
     710   paramètres de contrôle pour ce programme sont décrits dans <xref 
     711   linkend="runtime-config-logging-where"/>. Vous pouvez aussi utiliser cette 
     712   approche pour capturer les données des journaux applicatifs dans un format 
     713   CSV lisible par une machine 
    706714  </para> 
    707715 

  • traduc/trunk/manuel/queries.xml

    r747 r769  
    12201220 
    12211221  <para> 
    1222    The <literal>NULLS FIRST</literal> and <literal>NULLS LAST</literal> options can be 
    1223    used to determine whether nulls appear before or after non-null values 
    1224    in the sort ordering.  By default, null values sort as if larger than any 
    1225    non-null value; that is, <literal>NULLS FIRST</literal> is the default for 
    1226    <literal>DESC</literal> order, and <literal>NULLS LAST</literal> otherwise. 
    1227   </para> 
    1228  
    1229   <para> 
    1230    Note that the ordering options are considered independently for each 
    1231    sort column.  For example <literal>ORDER BY x, y DESC</literal> means 
    1232    <literal>ORDER BY x ASC, y DESC</literal>, which is not the same as 
     1222   Les options <literal>NULLS FIRST</literal> et <literal>NULLS LAST</literal> 
     1223   sont utilisées pour déterminer si les valeurs NULL apparaissent avant ou 
     1224   après les valeurs non NULL après un tri. Par défaut, les valeurs NULL sont 
     1225   triées comme si elles avaient une valeur plus importante que les valeurs non 
     1226   NULL&nbsp;; autrement dit <literal>NULLS FIRST</literal> est la valeur par 
     1227   défaut pour un tri descendant, alors que <literal>NULLS LAST</literal> est 
     1228   la valeur par défaut pour un tri ascendant. 
     1229  </para> 
     1230 
     1231  <para> 
     1232   Notez que les options de tri sont considérées indépendament pour chaque 
     1233   colonne triée. Par exemple, <literal>ORDER BY x, y DESC</literal> signifie 
     1234   en fait <literal>ORDER BY x ASC, y DESC</literal>, ce qui est différent de 
    12331235   <literal>ORDER BY x DESC, y DESC</literal>. 
    12341236  </para> 

  • traduc/trunk/manuel/regress.xml

    r751 r769  
    344344<synopsis>nomtest:sortie:modeleplateform=fichiercomparaison</synopsis> 
    345345    Le nom de tests est juste le nom du module de tests de régression 
    346     particulier. The output value indicates which output file to check. For the 
    347     standard regression tests, this is always <literal>out</literal>. The 
    348     value corresponds to the file extension of the output file. Le modèle de 
    349     plateforme est un modèle dans le style des outils 
     346    particulier. La valeur en sortie indique le fichier à vérifier. Pour les 
     347    tests de régression standards, c'est toujours <literal>out</literal>. La 
     348    valeur correspond à l'extension de fichier du fichier en sortie. Le modèle 
     349    de plateforme est un modèle dans le style des outils 
    350350    Unix <command>expr</command> (c'est-à-dire une expression rationnelle avec une 
    351351    ancre implicite <literal>^</literal> au début). Il est testé avec le nom de 

  • traduc/trunk/manuel/runtime.xml

    r752 r769  
    658658      <term><systemitem class="osname">AIX</systemitem></term> 
    659659      <listitem> 
    660       <indexterm><primary>AIX</primary><secondary>IPC configuration</secondary></indexterm> 
    661        <para> 
    662         At least as of version 5.1, it should not be necessary to do 
    663         any special configuration for such parameters as 
    664         <varname>SHMMAX</varname>, as it appears this is configured to 
    665         allow all memory to be used as shared memory.  That is the 
    666         sort of configuration commonly used for other databases such 
    667         as <application>DB/2</application>.</para> 
    668  
    669        <para> It might , however, be necessary to modify the global 
    670        <command>ulimit</command> information in 
    671        <filename>/etc/security/limits</filename>, as the default hard 
    672        limits for file sizes (<varname>fsize</varname>) and numbers of 
    673        files (<varname>nofiles</varname>) might be too low. 
     660      <indexterm><primary>AIX</primary><secondary>configuration IPC</secondary></indexterm> 
     661       <para> 
     662        À partir de la version 5.1, il ne doit plus être nécessaire de faire 
     663        une configuration spéciale pour les paramètres tels que 
     664        <varname>SHMMAX</varname>, car c'est configuré de façon à ce que toute 
     665        la mémoire puisse être utilisée en tant que mémoire partagée. 
     666        C'est le type de configuration habituellement utilisée pour d'autres 
     667        bases de données comme <application>DB/2</application>.</para> 
     668 
     669       <para> 
     670        Néanmoins, il pourrait être nécessaire de modifier l'information 
     671       globale <command>ulimit</command> dans 
     672       <filename>/etc/security/limits</filename> car les limites en dur par 
     673       défaut pour les tailles de fichiers (<varname>fsize</varname>) et 
     674       les nombres de fichiers (<varname>nofiles</varname>) pourraient être 
     675       trop bas. 
    674676       </para> 
    675677      </listitem> 
    …… 
    11781180    <productname>PostgreSQL</productname> sur une machine où vous pouvez vous 
    11791181    assurer que les autres processus ne mettront pas la machine en manque de 
    1180     mémoire. If memory is tight, increasing the swap space of the 
    1181     operating system can help avoiding the problem, because the 
    1182     out-of-memory (OOM) killer is invoked whenever physical memory and 
    1183     swap space are exhausted. 
    1184    </para> 
    1185  
    1186    <para> 
    1187     On Linux 2.6 and later, an additional measure is to modify the 
    1188     kernel's behavior so that it will not <quote>overcommit</quote> memory. 
    1189     Although this setting will not prevent the OOM killer from 
    1190     invoking altogether, it will lower the chances significantly and 
    1191     will therefore lead to more robust system behavior.  This is done 
    1192     by selecting strict overcommit mode via <command>sysctl</command>: 
     1182    mémoire. S'il y a peu de mémoire, augmenter la swap peut aider à éviter 
     1183    le problème car un système peut tuer des processus lorsque la mémoire 
     1184    physique et la mémoire swap sont utilisées entièrement. 
     1185   </para> 
     1186 
     1187   <para> 
     1188    Sur Linux 2.6 et ultérieur, une mesure supplémentaire revient à modifier 
     1189    le comportement du noyau avec le <quote>overcommit memory</quote>. 
     1190    Bien que ce paramétrage n'empêchera pas ce comportement, il réduira sa 
     1191    fréquence de façon significative et contribuera du coup à un système 
     1192    plus robuste. Ceci se fait en sélectionnant le mode strict de 
     1193    l'overcommit via <command>sysctl</command>&nbsp;: 
    11931194<programlisting>sysctl -w vm.overcommit_memory=2</programlisting> 
    11941195    ou en plaçant une entrée équivalente dans <filename>/etc/sysctl.conf</filename>. 
    …… 
    14871488 
    14881489  <para> 
    1489    <productname>OpenSSL</productname> supports a wide range of ciphers 
    1490    and authentication algorithms, whose strength varies significantly. 
    1491    You can restrict the list of ciphers that can be used to connect to 
    1492    your server by adjusting the <xref linkend="guc-ssl-ciphers"/> parameter. 
    1493   </para> 
    1494  
    1495   <para> 
    1496    <productname>PostgreSQL</productname> reads the system-wide 
    1497    <productname>OpenSSL</productname> configuration file. By default, this 
    1498    file is named <filename>openssl.cnf</filename> and is located in the 
    1499    directory reported by <literal>openssl version -d</literal>. 
    1500    This default can be overridden by setting environment variable 
    1501    <envar>OPENSSL_CONF</envar> to the name of the desired configuration file. 
     1490   <productname>OpenSSL</productname> supporte un grand ensemble 
     1491   d'algorithmes de chiffrement et d'authentification dont la force varie 
     1492   significativement. Vous pouvez restreindre la liste des algorithmes de 
     1493   chiffrement utilisés pour se connecter à votre serveur en ajustant le 
     1494   paramètre <xref linkend="guc-ssl-ciphers"/>. 
     1495  </para> 
     1496 
     1497  <para> 
     1498   <productname>PostgreSQL</productname> lit le fichier de configuration 
     1499   d'<productname>OpenSSL</productname> pour le serveur. Par défaut, ce 
     1500   fichier est nommé <filename>openssl.cnf</filename> et est situé dans le 
     1501   répertoire indiqué par <literal>openssl version -d</literal>. 
     1502   Cette valeur par défaut peut être surchargée en configurant la variable 
     1503   d'environnement <envar>OPENSSL_CONF</envar> avec le nom du fichier de 
     1504   configuration désiré. 
    15021505  </para> 
    15031506 

  • traduc/trunk/manuel/sources.xml

    r735 r769  
    231231   <listitem> 
    232232    <para> 
    233      <function>errhidestmt(bool hide_stmt)</function> can be called to specify 
    234      suppression of the <literal>STATEMENT:</literal> portion of a message in the 
    235      postmaster log.  Generally this is appropriate if the message text 
    236      includes the current statement already. 
     233     <function>errhidestmt(bool hide_stmt)</function> peut être appelé pour 
     234     indiquer la suppression de la portion <literal>STATEMENT:</literal> d'un 
     235     message dans le journal applicatif de postmaster. Habituellement, c'est 
     236     approprié si le texte du message contient déjà l'instruction en cours. 
    237237    </para> 
    238238   </listitem> 
    …… 
    663663    <title>May vs. Can vs. Might</title> 
    664664   <para> 
    665     <quote>May</quote> suggests permission (e.g. "You may borrow my rake."), 
    666     and has little use in documentation or error messages. 
    667     <quote>Can</quote> suggests ability (e.g. "I can lift that log."), 
    668     and <quote>might</quote> suggests possibility (e.g. "It might rain 
    669     today.").  Using the proper word clarifies meaning and assists 
    670     translation. 
     665    <quote>May</quote> suggère un droit (par exemple <foreignphrase>You may 
     666    borrow my rake.</foreignphrase>) et a peu d'utilité dans la documentation 
     667    et dans les messages d'erreur. 
     668    <quote>Can</quote> suggère une capacité (par exemple <foreignphrase>I can 
     669    lift that log.</foreignphrase>), et <quote>might</quote> suggère une 
     670    possibilité (par exemple <foreignphrase>It might rain today.</foreignphrase>). 
     671    Utiliser le bon mot clarifie la signification et aide les traducteurs. 
    671672   </para> 
    672673  </formalpara> 
    …… 
    675676    <title>Contractions</title> 
    676677   <para> 
    677     Avoid contractions, like <quote>can't</quote>;  use 
    678     <quote>cannot</quote> instead. 
     678    Éviter les contractions comme <quote>can't</quote>&nbsp;; utilisez 
     679    <quote>cannot</quote> à la place. 
    679680   </para> 
    680681  </formalpara> 

  • traduc/trunk/manuel/storage.xml

    r735 r769  
    184184 
    185185<para> 
    186 Temporary files (for operations such as sorting more data than can fit in 
    187 memory) are created within <varname>PGDATA</varname><filename>/base/pgsql_tmp</filename>, 
    188 or within a <filename>pgsql_tmp</filename> subdirectory of a tablespace directory 
    189 if a tablespace other than <literal>pg_default</literal> is specified for them. 
    190 The name of a temporary file has the form 
     186Les fichiers temporaires (pour des opérations comme le tri de plus de données 
     187que ce que la mémoire peut contenir) sont créés à l'intérieur de <varname>PGDATA</varname><filename>/base/pgsql_tmp</filename>, 
     188ou dans un sous-répertoire <filename>pgsql_tmp</filename> du répertoire du 
     189tablespace si un tablespace autre que <literal>pg_default</literal> est 
     190indiqué pour eux. Le nom du fichier temporaire est de la forme 
    191191<filename>pgsql_tmp<replaceable>PPP</replaceable>.<replaceable>NNN</replaceable></filename>, 
    192 where <replaceable>PPP</replaceable> is the PID of the owning backend and 
    193 <replaceable>NNN</replaceable> distinguishes different files of that backend. 
     192où <replaceable>PPP</replaceable> est le PID du serveur propriétaire et 
     193<replaceable>NNN</replaceable> distingue les différents fichiers de ce 
     194serveur. 
    194195</para> 
    195196 
    …… 
    239240 
    240241<para> 
    241 <acronym>TOAST</acronym> usurps two bits of the varlena length word (the high-order 
    242 bits on big-endian machines, the low-order bits on little-endian machines), 
    243 thereby limiting the logical size of any value of a <acronym>TOAST</acronym>-able 
    244 data type to 1 GB (2<superscript>30</superscript> - 1 bytes).  When both bits are zero, 
    245 the value is an ordinary un-<acronym>TOAST</acronym>ed value of the data type, and 
    246 the remaining bits of the length word give the total datum size (including 
    247 length word) in bytes.  When the highest-order or lowest-order bit is set, 
    248 the value has only a single-byte header instead of the normal four-byte 
    249 header, and the remaining bits give the total datum size (including length 
    250 byte) in bytes.  As a special case, if the remaining bits are all zero 
    251 (which would be impossible for a self-inclusive length), the value is a 
    252 pointer to out-of-line data stored in a separate TOAST table.  (The size of 
    253 a TOAST pointer is given in the second byte of the datum.) 
    254 Values with single-byte headers aren't aligned on any particular 
    255 boundary, either.  Lastly, when the highest-order or lowest-order bit is 
    256 clear but the adjacent bit is set, the content of the datum has been 
    257 compressed and must be decompressed before use.  In this case the remaining 
    258 bits of the length word give the total size of the compressed datum, not the 
    259 original data.  Note that compression is also possible for out-of-line data 
    260 but the varlena header does not tell whether it has occurred &mdash; 
    261 the content of the TOAST pointer tells that, instead. 
     242<acronym>TOAST</acronym> récupère deux bits du mot contenant la longueur 
     243d'un varlena (ceux de poids fort sur les machines big-endian, ceux de poids 
     244faible sur les machines little-endian), limitant du coup la taille logique 
     245de toute valeur d'un type de données <acronym>TOAST</acronym> à 1&nbsp;Go 
     246(2<superscript>30</superscript> - 1 octets). Quand les deux bits sont à 
     247zéro, la valeur est une valeur non <acronym>TOAST</acronym>é du type de 
     248données et les bits restants dans le mot contenant la longueur indique 
     249la taille total du datum (incluant ce mot) en octets. Quand le bit de poids 
     250fort (ou de poids faible) est à un, la valeur a un en-tête de seulement 
     251un octet alors qu'un en-tête normal en fait quatre. Les bits restants 
     252donne la taille total du datum (incluant ce mot) en octets. Il reste un 
     253cas spécial&nbsp;: si les bits restants sont tous à zéro (ce qui est 
     254impossible étant donné que le mot indiquant la longueur est inclut dans 
     255la taille), la valeur est un pointeur vers une donnée stockée dans une table 
     256TOAST séparée (la taille d'un pointeur TOAST est indiquée dans le second 
     257octet du datum). Les valeurs dont l'en-tête fait un seul octet ne sont pas 
     258alignées sur une limite particulière. Enfin, quand le bit de poids fort 
     259(ou de poids faible) est supprimé mais que le bit adjacent vaut un, le 
     260contenu du datum est compressé et doit être décompresser avant utilisation. 
     261Dans ce cas, les bits restants du mot contenant la longueur indiquent la 
     262taille totale du datum compressé, pas celles des données au départ. Notez 
     263que la compression est aussi possible pour les données de la table TOAST 
     264mais l'en-tête varlena n'indique pas si c'est le cas &mdash; le contenu 
     265du pointeur TOAST le précise. 
    262266</para> 
    263267 
    …… 
    278282<para> 
    279283Les valeurs hors-ligne sont divisées (après compression si nécessaire) en 
    280 morceaux d'au plus <literal>TOAST_MAX_CHUNK_SIZE</literal> octets (by default this value is chosen 
    281 so that four chunk rows will fit on a page, making it about 2000 bytes). Chaque morceau est stocké comme une ligne séparée dans la table 
     284morceaux d'au plus <literal>TOAST_MAX_CHUNK_SIZE</literal> octets (par défaut, 
     285cette valeur est choisie pour que quatre morceaux de ligne tiennent sur une 
     286page, d'où les 2000 octets). Chaque morceau est stocké comme une ligne séparée dans la table 
    282287<acronym>TOAST</acronym> de la table propriétaire. Chaque table <acronym>TOAST</acronym> 
    283288contient les colonnes <structfield>chunk_id</structfield> (un OID identifiant la valeur 
    …… 
    317322     <para> 
    318323      <literal>PLAIN</literal> empêche soit la compression soit le stockage 
    319       hors-ligne; furthermore it disables use of single-byte headers 
    320       for varlena types. Ceci est la seule stratégie possible pour les  
    321       colonnes des types de données non <acronym>TOAST</acronym>-ables. 
     324      hors-ligne&nbsp;; de plus, il désactive l'utilisation d'en-tête sur 
     325      un octet pour les types varlena. Ceci est la seule stratégie possible 
     326      pour les colonnes des types de données non 
     327      <acronym>TOAST</acronym>-ables. 
    322328     </para> 
    323329    </listitem> 
    …… 
    477483  (PageHeaderData). Son format est détaillé dans <xref 
    478484  linkend="pageheaderdata-table"/>. Les deux premiers champs traquent l'entrée 
    479   WAL la plus récente relative à cette page. Next is a 2-byte field 
    480   containing flag bits. Ils sont suivis par trois 
     485  WAL la plus récente relative à cette page. Ensuite se trouve un champ de 
     486  deux octets contenant des drapeaux. Ils sont suivis par trois 
    481487  champs d'entiers sur deux octets (<structfield>pd_lower</structfield>, 
    482488  <structfield>pd_upper</structfield> et 
    …… 
    497503  croisée&nbsp;; il n'existe pas de support pour avoir plus d'une taille de 
    498504  page dans une installation. 
    499   The last field is a hint that shows whether pruning the page is likely 
    500   to be profitable: it tracks the oldest un-pruned XMAX on the page. 
     505  Le dernier champ est une aide indiquant si traiter la page serait 
     506  profitable&nbsp;: il garde l'information sur le plus vieux XMAX non traité 
     507  de la page. 
    501508 </para> 
    502509  
    …… 
    567574   <entry>TransactionId</entry> 
    568575   <entry>4 bytes</entry> 
    569    <entry>Oldest unpruned XMAX on page, or zero if none</entry> 
     576   <entry>Plus vieux XMAX non traité sur la page, ou zéro si aucun</entry> 
    570577  </row> 
    571578 </tbody> 

  • traduc/trunk/manuel/typeconv.xml

    r747 r769  
    374374 
    375375<example> 
    376 <title>Factorial Operator Type Resolution</title> 
    377  
    378 <para> 
    379         There is only one factorial operator (postfix <literal>!</literal>) 
    380 defined in the standard catalog, and it takes an argument of type  
    381 <type>bigint</type>. 
    382 The scanner assigns an initial type of <type>integer</type> to the argument 
    383 in this query expression: 
     376<title>Résolution du type d'opérateur factoriel</title> 
     377 
     378<para> 
     379Il n'existe qu'un seul opérateur factoriel (<literal>!</literal> postfix) 
     380défini dans le catalogue standard. Il prend un argument de type 
     381<type>bigint</type>. Le scanner affecte au début le type <type>integer</type> 
     382à l'argument dans cette expression&nbsp;: 
    384383<screen> 
    385384SELECT 40 ! AS "40 factorial"; 
    …… 
    556555données.  De plus, l'argument de la fonction doit être soit un type 
    557556inconnu soit un type qui a une compatibilité binaire avec le type de 
    558 données nommés, or a type that could be converted to the named data type by 
    559 applying that type's I/O functions (that is, the conversion is either to or 
    560 from one of the standard string types).  When these conditions are met, 
    561 the function call is treated as a form of <literal>CAST</literal> specification. 
     557données nommés, soit un type qui peut être converti dans le type de données 
     558indiqué en appliquant les fonctions d'entrées/sorties du type (c'est-à-dire 
     559que la conversion est vers ou à partir d'un type standard de chaîne). Quand 
     560ces conditions sont rencontrées, l'appel de la fonction est traité sous la 
     561forme d'une spécification <literal>CAST</literal>. 
    562562  <footnote> 
    563563   <para> 
    564     The reason for this step is to support function-style cast specifications 
    565     in cases where there is not an actual cast function.  If there is a cast 
    566     function, it is conventionally named after its output type, and so there 
    567     is no need to have a special case.  See 
    568     <xref linkend="sql-createcast" endterm="sql-createcast-title"/> 
    569     for additional commentary. 
     564    La raison de cette étape est le support des spécifications de conversion 
     565    au format fonction pour les cas où la vraie fonction de conversion 
     566    n'existe pas. S'il existe une fonction de conversion, elle est 
     567    habituellement nommée suivant le nom du type en sortie et donc il n'est 
     568    pas nécessaire d'avoir un cas spécial. Pour plus d'informations, voir 
     569    <xref linkend="sql-createcast" endterm="sql-createcast-title"/>. 
    570570   </para> 
    571571  </footnote> 
    …… 
    728728</screen> 
    729729 
    730 This does not work because <type>integer</type> does not have an implicit cast 
    731 to <type>text</type>.  An explicit cast will work, however: 
     730Ceci ne fonctionne pas car <type>integer</type> n'a pas de conversion 
     731implicite vers <type>text</type>. Néanmoins, une conversion explicite 
     732fonctionnera&nbsp;: 
    732733<screen> 
    733734SELECT substr(CAST (1234 AS text), 3); 

  • traduc/trunk/manuel/xfunc.xml

    r739 r769  
    22072207      <listitem> 
    22082208       <para> 
    2209         path to <application>pg_config</application> program for the 
    2210         <productname>PostgreSQL</productname> installation to build against 
    2211         (typically just <literal>pg_config</literal> to use the first one in your 
     2209        chemin vers le programme <application>pg_config</application> indiquant 
     2210        l'installation de <productname>PostgreSQL</productname> qui sert à la 
     2211        construction (généralement <literal>pg_config</literal> pour utiliser 
     2212        le premier programme trouvé dans la variable d'environnement 
    22122213        <varname>PATH</varname>) 
    22132214       </para> 
    …… 
    22242225    install</literal> pour installer votre module. Par défaut, l'extension est 
    22252226    compilée et installée pour l'installation de 
    2226     <productname>PostgreSQL</productname> qui correspond à le premier programme 
    2227         commande <command>pg_config</command> trouvée dans votre chemin. You can 
    2228         use a different installation by setting <varname>PG_CONFIG</varname> to 
    2229        point to its <command>pg_config</command> program, either within the 
    2230        makefile or on the <literal>make</literal> command line. 
     2227    <productname>PostgreSQL</productname> qui correspond au premier programme 
     2228    <command>pg_config</command> trouvée dans votre chemin. Vous pouvez utiliser 
     2229    utiliser une autre installation en configurant <varname>PG_CONFIG</varname> 
     2230    pour qu'il pointe vers le bon <command>pg_config</command>, soit dans le 
     2231    fichier Makefile soit sur la ligne de commande de <literal>make</literal>. 
    22312232  </para> 
    22322233   
    22332234   <caution> 
    22342235    <para> 
    2235      Changing <varname>PG_CONFIG</varname> only works when building 
    2236      against <productname>PostgreSQL</productname> 8.3 or later. 
    2237      With older releases it does not work to set it to anything except 
    2238      <literal>pg_config</literal>; you must alter your <varname>PATH</varname> 
    2239      to select the installation to build against. 
     2236     Modifier <varname>PG_CONFIG</varname> fonctionne seulement en construisant 
     2237     à partir d'une installation <productname>PostgreSQL</productname> 8.3 ou 
     2238     ultérieure. Les anciennes versions ne l'utilisent pas&nbsp;; vous devez 
     2239     donc modifier votre variable <varname>PATH</varname> pour sélectionner 
     2240     la bonne installation. 
    22402241    </para> 
    22412242   </caution> 

  • traduc/trunk/manuel/xoper.xml

    r735 r769  
    330330     peut seulement renvoyer la valeur vrai pour des paires de valeurs droite et 
    331331     gauche qui correspondent au même code de découpage. Si deux valeurs sont 
    332      placées dans deux différents paquets (<quote>buckets</quote>), la jointure ne pourra 
    333      jamais les comparer avec la supposition implicite que le résultat de 
    334      l'opérateur de jointure doit être faux. Ainsi, il n'y a aucun sens à 
    335      spécifier <literal>hashes</literal> pour des opérateurs qui ne représentent 
    336      pas une certaine forme d'égalité. In most cases it is only practical to support 
    337      hashing for operators that take the same data type on both sides. 
    338      However, sometimes it is possible to design compatible hash functions 
    339      for two or more datatypes; that is, functions that will generate the 
    340      same hash codes for <quote>equal</quote> values, even though the values 
    341      have different representations.  For example, it's fairly simple 
    342      to arrange this property when hashing integers of different widths. 
     332     placées dans deux différents paquets (<quote>buckets</quote>), la jointure 
     333     ne pourra jamais les comparer avec la supposition implicite que le  
     334     résultat de l'opérateur de jointure doit être faux. Ainsi, il n'y a aucun 
     335     sens à spécifier <literal>hashes</literal> pour des opérateurs qui ne 
     336     représentent pas une certaine forme d'égalité. Dans la plupart des cas, il 
     337     est seulement pratique de supporter le hachage pour les opérateurs qui 
     338     prennent le même type de données sur chaque côté. Néanmoins, quelque 
     339     fois, il est possible de concevoir des fonctions de hachage compatibles 
     340     pour deux type de données, voire plus&nbsp;; c'est-à-dire pour les 
     341     fonctions qui généreront les mêmes codes de hachage pour des valeurs 
     342     égales même si elles ont des représentations différentes. Par exemple, 
     343     il est assez simple d'arranger cette propriété lors du hachage d'entiers 
     344     de largeurs différentes. 
    343345    </para> 
    344346 
    …… 
    374376 
    375377    <para> 
    376      A hash-joinable operator must have a commutator (itself if the two 
    377      operand data types are the same, or a related equality operator 
    378      if they are different) that appears in the same operator family. 
    379      If this is not the case, planner errors might occur when the operator 
    380      is used.  Also, it is a good idea (but not strictly required) for 
    381      a hash operator family that supports multiple datatypes to provide 
    382      equality operators for every combination of the datatypes; this 
    383      allows better optimization. 
     378     Un opérateur joignable par hachage doit avoir un commutateur (lui-même 
     379     si les types de données des deux opérandes sont identiques, ou un 
     380     opérateur d'égalité relatif dans le cas contraire) qui apparaît dans la 
     381     même famille d'opérateur. Si ce n'est pas le cas, des erreurs du 
     382     planificateur pourraient apparaître quand l'opérateur est utilisé. De plus, 
     383     une bonne idée (mais pas obligatoire) est qu'une famille d'opérateur de 
     384     hachage supporte les tupes de données multiples pour fournir des 
     385     opérateurs d'égalité pour chaque combinaison des types de données&nbsp;; 
     386     cela permet une meilleure optimisation. 
    384387    </para> 
    385388 
    …… 
    432435 
    433436    <para> 
    434      To be marked <literal>MERGES</literal>, the join operator must appear 
    435      as an equality member of a btree index operator family. 
    436      This is not enforced when you create 
    437      the operator, since of course the referencing operator family couldn't 
    438      exist yet.  But the operator will not actually be used for merge joins 
    439      unless a matching operator family can be found.  The 
    440      <literal>MERGES</literal> flag thus acts as a hint to the planner that 
    441      it's worth looking for a matching operator family. 
    442     </para> 
    443  
    444     <para> 
    445      A merge-joinable operator must have a commutator (itself if the two 
    446      operand data types are the same, or a related equality operator 
    447      if they are different) that appears in the same operator family. 
    448      If this is not the case, planner errors might occur when the operator 
    449      is used.  Also, it is a good idea (but not strictly required) for 
    450      a btree operator family that supports multiple datatypes to provide 
    451      equality operators for every combination of the datatypes; this 
    452      allows better optimization. 
     437     Pour être marqué <literal>MERGES</literal>, l'opérateur de jointure doit 
     438     apparaître en tant que membre d'égalité d'une famille opérateur d'index 
     439     btree. Ceci n'est pas forcé quand vous créez l'opérateur puisque, bien 
     440     sûr, la famille d'opérateur référente n'existe pas encore. Mais 
     441     l'opérateur ne sera pas utilisé pour les jointures d'assemblage sauf si 
     442     une famille d'opérateur correspondante est trouvée. L'option 
     443     <literal>MERGES</literal> agit en fait comme une aide pour le planificateur 
     444     lui indiquant qu'il est intéressant de chercher une famille d'opérateur 
     445     correspondant. 
     446    </para> 
     447 
     448    <para> 
     449     Un opérateur joignable par assemblage doit avoir un commutateur 
     450     (lui-même si les types de données des deux opérateurs sont identiques, 
     451     ou un opérateur d'égalité en relation dans le cas contraire) qui 
     452     apparaîtdans la même famille d'opérateur.  Si ce n'est pas le cas, des 
     453     erreurs du 
     454     planificateur pourraient apparaître quand l'opérateur est utilisé. De plus, 
     455     une bonne idée (mais pas obligatoire) est qu'une famille d'opérateur de 
     456     hachage supporte les tupes de données multiples pour fournir des 
     457     opérateurs d'égalité pour chaque combinaison des types de données&nbsp;; 
     458     cela permet une meilleure optimisation. 
    453459    </para> 
    454460 

  • traduc/trunk/manuel/xtypes.xml

    r735 r769  
    250250  Si les valeurs du type de données varient en taille (sous la forme interne), 
    251251  le type de données doit être marqué comme TOAST-able (voir 
    252   <xref linkend="storage-toast"/>). You should do this even if the data are always 
    253   too small to be compressed or stored externally because 
    254   <productname>Postgres</productname> can save space on small data using 
    255   <acronym>TOAST</acronym> as well. 
    256  </para> 
    257  
    258  <para> 
    259   To do this, the internal representation must follow the standard layout for 
    260   variable-length data: the first four bytes must be an <type>int32</type> 
    261   which is never accessed directly (customarily named <literal>vl_len_</literal>). You 
    262   must use <function>SET_VARSIZE()</function> to store the size of the datum 
    263   in this field and <function>VARSIZE()</function> to retrieve it. The C 
    264   functions operating on the data type must always be careful to unpack any 
    265   toasted values they are handed, by using <function>PG_DETOAST_DATUM</function>. 
    266   (This detail is customarily hidden by defining type-specific 
    267   <function>GETARG_DATATYPE_P</function> macros.) Then, when running the 
    268   <command>CREATE TYPE</command> command, specify the internal length as 
    269   <literal>variable</literal> and select the appropriate storage option. 
    270  </para> 
    271  
    272  <para> 
    273   If the alignment is unimportant (either just for a specific function or 
    274   because the data type specifies byte alignment anyways) then it's possible 
    275   to avoid some of the overhead of <function>PG_DETOAST_DATUM</function>. You can use 
    276   <function>PG_DETOAST_DATUM_PACKED</function> instead (customarily hidden by 
    277   defining a <function>GETARG_DATATYPE_PP</function> macro) and using the macros 
    278   <function>VARSIZE_ANY_EXHDR</function> and <function>VARDATA_ANY</function> macros. 
    279   Again, the data returned by these macros is not aligned even if the data 
    280   type definition specifies an alignment. If the alignment is important you 
    281   must go through the regular <function>PG_DETOAST_DATUM</function> interface. 
     252  <xref linkend="storage-toast"/>). Vous devez le faire même si les données sont 
     253  trop petites pour être compressées ou stockées en externe car 
     254  <productname>Postgres</productname> peut gagner de la place sur des petites 
     255  données en utilisant aussi <acronym>TOAST</acronym>. 
     256 </para> 
     257 
     258 <para> 
     259  Pour cela, la représentation interne doit suivre la disposition standard pour 
     260  les données de longueur variable&nbsp;: les quatre premiers octets doivent 
     261  être un <type>int32</type> dont l'accès n'est jamais direct (appelé 
     262  <literal>vl_len_</literal>). Vous devez utiliser 
     263  <function>SET_VARSIZE()</function> pour stocker la taille du datum dans ce 
     264  champ et <function>VARSIZE()</function> pour le récupérer. Les fonctions C 
     265  opérant sur ce type de données doivent toujours faire attention à déballer 
     266  toutes valeurs TOAST qu'elles récupèrent en utilisant 
     267  <function>PG_DETOAST_DATUM</function> (ce détail est habituellement caché 
     268  en définissant des macros <function>GETARG_DATATYPE_P</function> spécifiques 
     269  au type). Ensuite, lors de l'exécution de la commande <command>CREATE 
     270  TYPE</command>, précisez la longueur interne comme <literal>variable</literal> 
     271  et sélectionnez l'option de stockage approprié. 
     272 </para> 
     273 
     274 <para> 
     275  Si l'alignement n'est pas important (soit seulement pour une fonction 
     276  spécifique soit parce que le type de données spécifie un alignement par 
     277  octet), alors il est possible d'éviter 
     278  <function>PG_DETOAST_DATUM</function>. Vous pouvez utiliser 
     279  <function>PG_DETOAST_DATUM_PACKED</function> à la place (habituellement 
     280  caché par une macro <function>GETARG_DATATYPE_PP</function>) et utiliser les 
     281  macros <function>VARSIZE_ANY_EXHDR</function> et 
     282  <function>VARDATA_ANY</function>. 
     283  Encore une fois, les données renvoyées par ces macros ne sont pas alignées 
     284  même si la définition du type de données indique un alignement. Si 
     285  l'alignement est important pour vous, vous devez passer par l'interface 
     286  habituelle, <function>PG_DETOAST_DATUM</function>. 
    282287 </para> 
    283288