[Trad] [svn:pgfr] r1352 - in traduc/trunk/postgresql: . ref
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Mer 24 Juin 00:14:32 CEST 2009
Author: gleu
Date: 2009-06-24 00:14:31 +0200 (Wed, 24 Jun 2009)
New Revision: 1352
Modified:
traduc/trunk/postgresql/array.xml
traduc/trunk/postgresql/config.xml
traduc/trunk/postgresql/datatype.xml
traduc/trunk/postgresql/dblink.xml
traduc/trunk/postgresql/ddl.xml
traduc/trunk/postgresql/func.xml
traduc/trunk/postgresql/gist.xml
traduc/trunk/postgresql/indices.xml
traduc/trunk/postgresql/installation.xml
traduc/trunk/postgresql/maintenance.xml
traduc/trunk/postgresql/mvcc.xml
traduc/trunk/postgresql/perform.xml
traduc/trunk/postgresql/plpgsql.xml
traduc/trunk/postgresql/queries.xml
traduc/trunk/postgresql/query.xml
traduc/trunk/postgresql/ref/alter_foreign_data_wrapper.xml
traduc/trunk/postgresql/ref/alter_server.xml
traduc/trunk/postgresql/ref/alter_user_mapping.xml
traduc/trunk/postgresql/ref/create_foreign_data_wrapper.xml
traduc/trunk/postgresql/ref/create_server.xml
traduc/trunk/postgresql/ref/create_user_mapping.xml
traduc/trunk/postgresql/ref/drop_foreign_data_wrapper.xml
traduc/trunk/postgresql/ref/drop_server.xml
traduc/trunk/postgresql/ref/drop_user_mapping.xml
traduc/trunk/postgresql/ref/move.xml
traduc/trunk/postgresql/release-8.4.xml
traduc/trunk/postgresql/rowtypes.xml
traduc/trunk/postgresql/start.xml
traduc/trunk/postgresql/storage.xml
traduc/trunk/postgresql/syntax.xml
traduc/trunk/postgresql/textsearch.xml
traduc/trunk/postgresql/typeconv.xml
traduc/trunk/postgresql/version.xml
traduc/trunk/postgresql/xaggr.xml
Log:
Mise ?\195?\160 jour vers la RC2.
Modified: traduc/trunk/postgresql/array.xml
===================================================================
--- traduc/trunk/postgresql/array.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/array.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -65,8 +65,8 @@
De plus, l'implantation actuelle n'oblige pas non plus à déclarer le
nombre de dimensions. Les tableaux d'un type d'élément particulier sont tous
considérés comme étant du même type, quelque soit leur taille ou le
- nombre de dimensions. Déclarer le nombre de dimensions ou la taille dans
- <command>CREATE TABLE</command> n'a qu'un but documentaire. Le
+ nombre de dimensions. Déclarer la taille du tableau ou le nombre de dimensions
+ dans <command>CREATE TABLE</command> n'a qu'un but documentaire. Le
comportement de l'application n'en est pas affecté.
</para>
@@ -108,7 +108,7 @@
type, tel qu'il est enregistré dans son entrée <literal>pg_type</literal>.
Parmi les types de données standard fournis par la distribution
<productname>PostgreSQL</productname>, tous utilisent une virgule
- (<literal>,</literal>), sauf pour le type <literal>box</literal> qui utilise
+ (<literal>,</literal>), sauf pour le type <type>box</type> qui utilise
un point-virgule (<literal>;</literal>). Chaque <replaceable>val</replaceable> est soit une constante
du type des éléments du tableau soit un sous-tableau.
</para>
@@ -576,9 +576,9 @@
délimitation entre éléments adjacents. Le caractère délimiteur est
habituellement une virgule (<literal>,</literal>) mais peut différer :
il est déterminé par le paramètre <literal>typdelim</literal> du type de l'élément
- tableau (parmi les types de données standards supportés par l'implantation
- de <productname>PostgreSQL</productname>, seul le type <literal>box</literal> utilise un
- point-virgule (<literal>;</literal>), tous les autres utilisant la virgule).
+ tableau. Parmi les types de données standards supportés par l'implantation
+ de <productname>PostgreSQL</productname>, seul le type <type>box</type> utilise un
+ point-virgule (<literal>;</literal>), tous les autres utilisant la virgule.
Dans un tableau multidimensionnel, chaque dimension (row, plane, cube, etc.)
utilise son propre niveau d'accolades et les délimiteurs doivent être
utilisés entre des entités adjacentes au sein d'accolades de même niveau.
@@ -636,10 +636,10 @@
<para>
Comme indiqué précédemment, lors de l'écriture d'une valeur de tableau,
des guillemets doubles peuvent être utilisés autour de chaque élément
- individuel du
- tableau. Il <emphasis>faut</emphasis> le faire si leur absence autour d'un élément
- induit en erreur l'analyseur de la valeur du tableau. Par exemple, les
- éléments contenant des crochets, virgules (ou tout caractère délimiteur correspondant),
+ individuel du tableau. Il <emphasis>faut</emphasis> le faire si leur absence
+ autour d'un élément induit en erreur l'analyseur de la valeur du tableau.
+ Par exemple, les éléments contenant des crochets, virgules (ou tout type de
+ données pour le caractère délimiteur correspondant),
guillemets doubles, antislashs ou espace (en début comme en fin) doivent
avoir des guillemets doubles. Les chaînes vides et les chaînes <literal>NULL</literal>
doivent aussi être entre guillemets. Pour placer un guillemet double ou un antislash
Modified: traduc/trunk/postgresql/config.xml
===================================================================
--- traduc/trunk/postgresql/config.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/config.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -1354,8 +1354,8 @@
<function>posix_fadvise</function> efficace, ce que n'ont pas certains
systèmes d'exploitation. Si la fonction n'est pas présente, alors
positionner ce paramètre à une valeur autre que zéro entraînera une
- erreur. Sur certains systèmes, cette fonction est présente mais n'a
- pas d'effet (par exemple Solaris).
+ erreur. Sur certains systèmes (par exemple Solaris), cette fonction
+ est présente mais n'a pas d'effet.
</para>
</listitem>
</varlistentry>
Modified: traduc/trunk/postgresql/datatype.xml
===================================================================
--- traduc/trunk/postgresql/datatype.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/datatype.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -463,7 +463,7 @@
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.
+ de plate-forme sur laquelle il en va ainsi.
</para>
<para>
@@ -806,7 +806,7 @@
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
+ s'assurer qu'une valeur NULL ne puisse pas être
insérée. (Dans la plupart des cas, une
contrainte <literal>UNIQUE</literal> ou <literal>PRIMARY KEY</literal>
peut être ajoutée pour
@@ -860,8 +860,8 @@
<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"/>.
- La précision de la partie fractionnée est contrôlée par la locale de
- la base de données.
+ La précision de la partie fractionnée est déterminée par le paramètre
+ <xref linkend="guc-lc-monetary"/> de la base de données.
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>.
@@ -869,7 +869,8 @@
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> :
+ numérique en <type>text</type> puis en <type>money</type>, par
+ exemple :
<programlisting>
SELECT 1234::text::money;
</programlisting>
@@ -1072,16 +1073,18 @@
<tip>
<para>
- Il n'y a aucune différence de performance entre ces trois types, si ce
+ Il n'y a aucune différence de performance parmi 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.
+ <productname>PostgreSQL</productname> ; en fait,
+ <type>character(<replaceable>n</replaceable>)</type> est habituellement le
+ plus lent des trois à cause des coûts de stockage supplémentaires. Dans la
+ plupart des situations, les types <type>text</type> et <type>character
+ varying</type> peuvent être utilisés à leur place.
</para>
</tip>
@@ -1812,7 +1815,7 @@
</row>
<row>
<entry><literal>04:05 AM</literal></entry>
- <entry>Identique à 04:05 (AM est ignoré)</entry>
+ <entry>Identique à 04:05 ; AM n'affecte pas la valeur</entry>
</row>
<row>
<entry><literal>04:05 PM</literal></entry>
@@ -1950,9 +1953,8 @@
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 symbole
- <quote>+</quote> ou d'un <quote>-</quote> après l'indication du
- fuseau horaire. De ce fait, d'après le
- standard,
+ <quote>+</quote> ou d'un <quote>-</quote> et le déclage du fuseau horaire
+ après l'indication du temps. 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>
@@ -2126,9 +2128,8 @@
Le format de sortie des types date/heure peut être positionné à l'un des
quatre formats de date suivants : ISO 8601, <acronym>SQL</acronym>
(Ingres), traditionnel <productname>POSTGRES</productname> (date au format
- Unix <application>date</application>) et German
- (germanique). Cela se fait à l'aide de la commande
- <literal>SET datestyle</literal>. Le format par défaut est le format
+ Unix <application>date</application>) ou German
+ (germanique). Le format par défaut est le format
<acronym>ISO</acronym>. (Le standard <literal>SQL</literal> impose l'utilisation du format
ISO 8601. Le nom du format d'affichage <quote>SQL</quote> est mal choisi,
un accident historique.) Le
@@ -2803,7 +2804,7 @@
<member><literal>'off'</literal></member>
<member><literal>'0'</literal></member>
</simplelist>
- Les espaces avant et après, ainsi que la casse, sont ignorés.
+ Les espaces avant ou après, ainsi que la casse, sont ignorés.
Il est recommandé d'utiliser <literal>TRUE</literal> et
<literal>FALSE</literal> (qui sont compatibles avec la norme
<acronym>SQL</acronym>).
@@ -3167,7 +3168,7 @@
<para>
Les rectangles sont affichés selon la première syntaxe. Les deux coins
- opposés peuvent être fournis ; les coins sont ré-ordonnés en entrée
+ opposés peuvent être fournis en entrée mais les valeurs seront ré-ordonnés
pour stocker les coins en haut à droite et en bas à gauche.
</para>
</sect2>
@@ -3203,7 +3204,7 @@
</para>
<para>
- Les chemins sont affichés selon la première syntaxe appropriée.
+ Les chemins sont affichés selon la première ou la seconde syntaxe appropriée.
</para>
</sect2>
@@ -3657,7 +3658,7 @@
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 stocké dans une forme optimisé pour la recherche plein texte alors que le
+ document dans une forme optimisée pour la 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
@@ -3972,8 +3973,9 @@
<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>
+ à une déclaration de type de document (DTD),
+ <indexterm><primary>DTD</primary></indexterm>
+ même quand la valeur en entrée indique une DTD.
</para>
<para>
Modified: traduc/trunk/postgresql/dblink.xml
===================================================================
--- traduc/trunk/postgresql/dblink.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/dblink.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -51,9 +51,10 @@
</para>
<para>
- La chaîne de connexion peut aussi être le nom d'un serveur distant existant
- qui utilise la bibliothèque postgresql_fdw comme wrapper de données
- distantes. Voir l'exemple ci-dessous, ainsi que :
+ La chaîne de connexion peut aussi être le nom d'un serveur distant existant.
+ Il est recommandé d'utiliser <function>postgresql_fdw_validator</function>
+ lors de la définition d'un wrapper de données distantes correspondant. Voir
+ l'exemple ci-dessous, ainsi que :
<simplelist type="inline">
<member><xref linkend="sql-createforeigndatawrapper" endterm="sql-createforeigndatawrapper-title"/></member>
<member><xref linkend="sql-createserver" endterm="sql-createserver-title"/></member>
@@ -146,7 +147,7 @@
-- DETAIL: Non-superuser cannot connect if the server does not request a password.
-- HINT: Target server's authentication method must be changed.
CREATE USER dblink_regression_test WITH PASSWORD 'secret';
- CREATE FOREIGN DATA WRAPPER postgresql;
+ CREATE FOREIGN DATA WRAPPER postgresql VALIDATOR postgresql_fdw_validator;
CREATE SERVER fdtest FOREIGN DATA WRAPPER postgresql OPTIONS (hostaddr '127.0.0.1', dbname 'contrib_regression');
CREATE USER MAPPING FOR dblink_regression_test SERVER fdtest OPTIONS (user 'dblink_regression_test', password 'secret');
Modified: traduc/trunk/postgresql/ddl.xml
===================================================================
--- traduc/trunk/postgresql/ddl.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/ddl.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -2657,12 +2657,12 @@
SELECT count(*) FROM mesure WHERE date_trace >= DATE '2008-01-01';</programlisting>
Sans exclusion de contrainte, la requête ci-dessus parcourt chacune
- des partitions de la table <structname>mesure</structname>. Avec l'exclusion de
- contrainte activée, le planificateur examine les contraintes de chaque
- partition et tente de déterminer les partitions qui n'ont pas besoin d'être
- parcourues parce qu'elles ne peuvent pas contenir de lignes correspondant à
- la clause <literal>WHERE</literal> de la requête. Quand le planificateur peut le
- déterminer, il exclut la partition du plan de requête.
+ des partitions de la table <structname>mesure</structname>. Avec l'exclusion
+ de contrainte activée, le planificateur examine les contraintes de chaque
+ partition et tente de prouver que la partition qui n'a pas besoin d'être
+ parcourue parce qu'elle ne peut pas contenir de lignes correspondant à
+ la clause <literal>WHERE</literal> de la requête. Quand le planificateur peut
+ le prouver, il exclut la partition du plan de requête.
</para>
<para>
Modified: traduc/trunk/postgresql/func.xml
===================================================================
--- traduc/trunk/postgresql/func.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/func.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -274,8 +274,8 @@
<synopsis><replaceable>a</replaceable> BETWEEN <replaceable>x</replaceable> AND <replaceable>y</replaceable></synopsis>
est équivalent à
<synopsis><replaceable>a</replaceable> >= <replaceable>x</replaceable> AND <replaceable>a</replaceable> <= <replaceable>y</replaceable></synopsis>
- Notez que <token>BETWEEN</token> est inclusif dans sa comparaison des
- valeurs finales. <literal>NOT BETWEEN</literal> fait la comparaison
+ Notez que <token>BETWEEN</token> traite le point final comme inclut dans
+ l'échelle des valeurs. <literal>NOT BETWEEN</literal> fait la comparaison
inverse :
<synopsis><replaceable>a</replaceable> NOT BETWEEN <replaceable>x</replaceable> AND <replaceable>y</replaceable></synopsis>
est équivalent à
@@ -283,10 +283,10 @@
<indexterm>
<primary>BETWEEN SYMMETRIC</primary>
</indexterm>
- <token>BETWEEN SYMMETRIC</token> est identique à <literal>BETWEEN</literal> sauf qu'il
+ <literal>BETWEEN SYMMETRIC</literal> est identique à <literal>BETWEEN</literal> sauf qu'il
n'est pas nécessaire que l'argument à gauche de <literal>AND</literal> soit plus
- petit ou égal à l'argument à droite ; la bonne échelle de valeurs
- est déterminée automatiquement.
+ petit ou égal à l'argument à droite. SI ce n'est pas le cas, ces deux arguments sont
+ automatiquement inversés, pour qu'une échelle non vide soit toujours supposée.
</para>
<para>
@@ -362,8 +362,9 @@
</indexterm>
L'opérateur standard de comparaison renvoie NULL (ce qui signifie
<quote>inconnu</quote>) si l'une des entrées est NULL, ni true ni false,
- c'est-à-dire <literal>7 = NULL</literal> renvoie NULL. Une autre façon
- d'effectuer les comparaisons utilise la syntaxe <literal>IS <optional>NOT</optional> DISTINCT FROM</literal> :
+ c'est-à-dire <literal>7 = NULL</literal> renvoie NULL. Quand ce comportement
+ n'est pas convenable, utilisez la syntaxe <literal>IS
+ <optional>NOT</optional> DISTINCT FROM</literal> :
<synopsis>
<replaceable>expression</replaceable> IS DISTINCT FROM <replaceable>expression</replaceable>
<replaceable>expression</replaceable> IS NOT DISTINCT FROM <replaceable>expression</replaceable>
@@ -439,10 +440,9 @@
<para>
Des opérateurs mathématiques sont fournis pour un grand nombre de types
- <productname>PostgreSQL</productname>. Pour les types qui supportent
- seulement des opérations mathématiques limitées (les types
- dates/time, par exemple), le comportement réel est décrit dans les
- sections appropriées.
+ <productname>PostgreSQL</productname>. Pour les types sans conventions
+ mathématiques standards (les types dates/time, par exemple), le
+ comportement réel est décrit dans les sections appropriées.
</para>
<para>
@@ -1069,11 +1069,12 @@
</para>
<para>
- <acronym>SQL</acronym> définit quelques fonctions de type chaîne avec une
- syntaxe particulière où des mots clés sont utilisés à la place de la
- virgule pour séparer les arguments. Des détails sont disponibles dans le
- <xref linkend="functions-string-sql"/>. Ces fonctions sont aussi
- implantées en utilisant la syntaxe habituelle d'appel de fonctions
+ <acronym>SQL</acronym> définit quelques fonctions de type chaîne qui
+ utilisent des mots clés, à la place de la virgule, pour séparer les
+ arguments. Des détails sont disponibles dans le
+ <xref linkend="functions-string-sql"/>. <productname>PostgreSQL</productname>
+ fournit aussi des versions de ces fonctions qui utilisent la syntaxe
+ standard d'appel des fonctions
(voir le <xref linkend="functions-string-other"/>).
</para>
@@ -2720,11 +2721,11 @@
<para>
<acronym>SQL</acronym> définit quelques fonctions de chaînes qui utilise
- une syntaxe de mots clés qui sont employés à la place de
+ des mots clés qui sont employés à la place de
virgules pour séparer les arguments. Les détails sont présentés dans
- <xref linkend="functions-binarystring-sql"/>. Quelques fonctions sont aussi
- implantées avec la syntaxe habituelle de l'appel de fonction
- (voir le <xref linkend="functions-binarystring-other"/>).
+ <xref linkend="functions-binarystring-sql"/>. <productname>PostgreSQL</productname>
+ fournit aussi des versions de ces fonctions qui utilisant la syntaxe standard
+ de l'appel de fonction (voir le <xref linkend="functions-binarystring-other"/>).
</para>
<table id="functions-binarystring-sql">
@@ -3188,7 +3189,8 @@
sélectionnant un autre caractère d'échappement avec
<literal>ESCAPE</literal> ; un antislash n'est alors plus spécial
au regard de <function>LIKE</function> (mais il est toujours spécial pour
- l'analyseur de chaînes littérales, et nécessite toujours d'être doublé).
+ l'analyseur de chaînes littérales, et nécessite toujours d'être doublé
+ pour correspondre à un antislash).
</para>
<para>
@@ -3298,7 +3300,7 @@
</listitem>
</itemizedlist>
- Les répétitions encadrées (<literal>?</literal> et <literal>{...}</literal>) ne sont
+ Les opérateurs de répétitions encadrées (<literal>?</literal> et <literal>{...}</literal>) ne sont
pas permises bien qu'elles existent en POSIX. De même, le point
(<literal>.</literal>) n'est pas un méta-caractère.
</para>
@@ -3738,7 +3740,8 @@
Une <firstterm>contrainte</firstterm> établit une correspondance avec une
chaîne vide, mais cette correspondance n'est établie que lorsque des
conditions spécifiques sont remplies.
- Une contrainte ne peut pas être suivie d'un quantificateur.
+ Une contrainte peut être utilisée là où un atome peut l'être et
+ ne peut pas être suivie d'un quantificateur.
Les contraintes simples sont affichées dans le <xref
linkend="posix-constraints-table"/> ; quelques contraintes
supplémentaires sont décrites plus loin.
@@ -4256,7 +4259,7 @@
<entry>(où <replaceable>wxyz</replaceable> représente exactement quatre chiffres
hexadécimaux) le caractère UTF16 (Unicode, 16 bits)
<literal>U+</literal><replaceable>wxyz</replaceable>
- dans l'encodage local des octets</entry>
+ dans l'ordre local des octets</entry>
</row>
<row>
@@ -4273,10 +4276,10 @@
</row>
<row>
- <entry><literal>\x</literal><replaceable>###</replaceable> </entry>
- <entry>(où <replaceable>###</replaceable> représente toute séquence de chiffres
+ <entry><literal>\x</literal><replaceable>hhh</replaceable> </entry>
+ <entry>(où <replaceable>hhh</replaceable> représente toute séquence de chiffres
hexadécimaux) le caractère dont la valeur hexadécimale est
- <literal>0x</literal><replaceable>###</replaceable>
+ <literal>0x</literal><replaceable>hhh</replaceable>
(un simple caractère, peu importe le nombre de chiffres hexadécimaux
utilisés)
</entry>
@@ -4288,19 +4291,19 @@
</row>
<row>
- <entry><literal>\</literal><replaceable>##</replaceable> </entry>
- <entry>(où <replaceable>##</replaceable> représente exactement deux chiffres
+ <entry><literal>\</literal><replaceable>xy</replaceable> </entry>
+ <entry>(où <replaceable>xy</replaceable> représente exactement deux chiffres
octaux et n'est pas une <firstterm>rétro-référence</firstterm>)
le caractère dont la valeur octale est
- <literal>0</literal><replaceable>##</replaceable> </entry>
+ <literal>0</literal><replaceable>xy</replaceable> </entry>
</row>
<row>
- <entry><literal>\</literal><replaceable>###</replaceable> </entry>
- <entry>(où <replaceable>###</replaceable> représente exactement trois chiffres
+ <entry><literal>\</literal><replaceable>xyz</replaceable> </entry>
+ <entry>(où <replaceable>xyz</replaceable> représente exactement trois chiffres
octaux et n'est pas une <firstterm>rétro-référence</firstterm>)
le caractère dont la valeur octale est
- <literal>0</literal><replaceable>###</replaceable> </entry>
+ <literal>0</literal><replaceable>xyz</replaceable> </entry>
</row>
</tbody>
</tgroup>
@@ -4471,7 +4474,7 @@
<para>
Une ambiguïté persiste entre les échappements
de caractère octal et les rétro-références. Cette ambiguïté est résolue par
- des heuristiques, comme montré ci-dessus. Un zéro en début de chaîne indique
+ les heuristiques suivantes, comme montré ci-dessus. Un zéro en début de chaîne indique
toujours un échappement octal. Un caractère seul différent de zéro, qui
n'est pas suivi d'un autre caractère, est toujours pris comme une rétro-référence. Une
séquence à plusieurs chiffres qui ne débute pas par zéro est prise comme
@@ -5376,7 +5379,7 @@
</row>
<row>
<entry>suffixe <literal>SP</literal></entry>
- <entry>mode épelé (<foreignphrase>Spell Mode</foreignphrase>) (non supporté)</entry>
+ <entry>mode épelé (<foreignphrase>Spell Mode</foreignphrase>) (non implanté)</entry>
<entry><literal>DDSP</literal></entry>
</row>
</tbody>
@@ -5682,8 +5685,8 @@
<literal>10^<replaceable>n</replaceable></literal>, où
<replaceable>n</replaceable> est le nombre de chiffres qui suit
<literal>V</literal>. <function>to_char</function> ne supporte pas
- l'utilisation de <literal>V</literal> combiné avec des valeurs non
- entières (donc <literal>99.9V99</literal> n'est pas autorisé).
+ l'utilisation de <literal>V</literal> combiné avec un point décimal
+ (donc <literal>99.9V99</literal> n'est pas autorisé).
</para>
</listitem>
</itemizedlist>
@@ -6539,7 +6542,7 @@
<para>
Pour les valeurs de type <type>date</type> et <type>timestamp</type>,
le nombre de secondes depuis le 1er janvier 1970 (exactement depuis le
- 1970-01-01 00:00:00-00 GMT). Ce nombre peut être négatif. Pour les valeurs de
+ 1970-01-01 00:00:00 UTC). Ce nombre peut être négatif. Pour les valeurs de
type <type>interval</type>, il s'agit du nombre total de secondes dans
l'intervalle.
</para>
@@ -7100,6 +7103,9 @@
</para>
<para>
+ <function>transaction_timestamp()</function> est un peu l'équivalent de
+ <function>CURRENT_TIMESTAMP</function> mais est nommé ainsi pour expliciter
+ l'information retournée.
<function>statement_timestamp()</function> renvoie l'heure de début de
l'instruction en cours (plus exactement, l'heure de réception du
dernier message de la commande en provenance du client).
@@ -7115,9 +7121,6 @@
une valeur de type <type>timestamp with time zone</type>.
<function>now()</function> est l'équivalent traditionnel <productname>PostgreSQL</productname>
de <function>CURRENT_TIMESTAMP</function>.
- <function>transaction_timestamp()</function> est un peu l'équivalent de
- <function>CURRENT_TIMESTAMP</function> mais est nommé ainsi pour expliciter
- l'information retournée.
</para>
<para>
@@ -8713,9 +8716,9 @@
<para>
L'expression <function>xmlroot</function> modifie les propriétés du
n½ud racine d'une valeur XML. Si une version est indiquée, elle
- remplace la valeur dans la déclaration de version. Si une valeur
- « standalone » est indiquée, elle remplace la valeur dans la
- déclaration « standalone ».
+ remplace la valeur dans la déclaration de version du nœud racine.
+ Si un paramètre « standalone » est spécifié, il remplace la valeur dans la
+ déclaration « standalone » du nœud racine.
</para>
<para>
@@ -9387,16 +9390,17 @@
END</synopsis>
Les clauses <token>CASE</token> peuvent être utilisées partout où une
- expression est valide. <replaceable>condition</replaceable> est une
+ expression est valide. Chaque <replaceable>condition</replaceable> est une
expression qui renvoie un résultat de type <type>boolean</type>. Si le
- résultat est vrai, alors la valeur de l'expression <token>CASE</token>
- est le <replaceable>résultat</replaceable> qui suit la condition. Si le
- résultat est faux, toutes les clauses <token>WHEN</token> suivantes sont
+ résultat de la condition est vrai, alors la valeur de l'expression
+ <token>CASE</token> est le <replaceable>résultat</replaceable> qui suit la
+ condition. Si le résultat de la condition n'est pas vrai, toutes les clauses
+ <token>WHEN</token> suivantes sont
parcourues de la même façon. Si aucune <replaceable>condition</replaceable>
- <token>WHEN</token> n'est vraie, alors la valeur de l'expression est le
- <replaceable>résultat</replaceable> de la clause <token>ELSE</token>. Si la
- clause <token>ELSE</token> est omise et qu'aucune condition ne correspond,
- alors le résultat est nul.
+ <token>WHEN</token> n'est vraie, alors la valeur de l'expression
+ <token>CASE</token> est le <replaceable>résultat</replaceable> de la clause
+ <token>ELSE</token>. Si la clause <token>ELSE</token> est omise et
+ qu'aucune condition ne correspond, alors le résultat est nul.
</para>
<para>
@@ -9442,8 +9446,8 @@
<optional>ELSE <replaceable>résultat</replaceable></optional>
END</synopsis>
- L'<replaceable>expression</replaceable> est calculée et comparée à toutes
- les indications de <replaceable>valeur</replaceable> des clauses
+ La première <replaceable>expression</replaceable> est calculée et comparée à chacune
+ des <replaceable>valeur</replaceable> des clauses
<token>WHEN</token> jusqu'à en trouver une égale. Si aucune ne correspond, le
<replaceable>résultat</replaceable> de la clause
<token>ELSE</token> (ou une valeur NULL) est renvoyé(e). C'est similaire
@@ -10174,9 +10178,10 @@
Pour <function>any</function> et <function>some</function>, il
semble qu'il y a une ambiguïté dans la syntaxe standard :
<programlisting>SELECT b1 = ANY((SELECT b2 FROM t2 ...)) FROM t1 ...;</programlisting>
- Ici, <function>ANY</function> peut être considéré à la fois comme une
- sous-requête ou comme un agrégat si l'expression de sélection ne renvoie
- qu'une ligne. Du coup, le nom standard ne peut être donné à ces
+ Ici, <function>ANY</function> peut être considéré soit comme introduisant
+ une sous-requête soit comme étant une fonction d'agrégat, si la sous-requête
+ renvoit une ligne avec une valeur booléenne si l'expression de sélection ne
+ renvoie qu'une ligne. Du coup, le nom standard ne peut être donné à ces
agrégats.
</para>
</note>
@@ -12714,7 +12719,7 @@
du déclencheur</entry>
</row>
<row>
- <entry><literal><function>pg_get_userbyid</function>(<parameter>roleid</parameter>)</literal></entry>
+ <entry><literal><function>pg_get_userbyid</function>(<parameter>role_oid</parameter>)</literal></entry>
<entry><type>name</type></entry>
<entry>récupère le nom du rôle possédant cet OID</entry>
</row>
@@ -13073,7 +13078,7 @@
<row>
<entry><type>xmax</type></entry>
<entry>
- Premier txid non encore assigné. Tous les txids qui suivent celui-ci ne sont
+ Premier txid non encore assigné. Tous les txids plus grands ou égals à celui-ci ne sont
pas encore démarrés à ce moment de l'instantané, et donc invisibles.
</entry>
</row>
@@ -13084,7 +13089,7 @@
Active les identifiants de transactions (txids) au moment de la prise
de l'image. La liste inclut seulement les identifiants actifs entre
<literal>xmin</literal> et <literal>xmax</literal> ; il pourrait
- y avoir des identifiants plus gros que xmax. Un identifiant qui est
+ y avoir des identifiants plus gros que <literal>xmax</literal>. Un identifiant qui est
<literal>xmin <= txid < xmax</literal> et qui n'est pas dans cette
liste est déjà terminé au moment de la prise de l'image, et du coup est
soit visible soit mort suivant son statut de validation. La liste
@@ -13558,9 +13563,8 @@
</entry>
<entry><type>bigint</type></entry>
<entry>
- Espace disque utilisé par le fork indiqué, <literal>'main'</literal> ou
- <literal>'fsm'</literal>, d'une table ou index d'OID ou de nom indiqué.
- Le nom de la table peut être qualifié avec un nom de schéma.
+ Espace disque utilisé par le fork indiqué, <literal>'main'</literal>,
+ <literal>'fsm'</literal> ou <literal>'vm'</literal>, d'une table ou index d'OID ou de nom indiqué.
</entry>
</row>
<row>
@@ -13603,8 +13607,7 @@
<entry><type>bigint</type></entry>
<entry>
Espace disque total utilisé par la table de cet OID ou nom, incluant
- les index et les données de la partie TOAST. Le nom de la table peut
- être qualifié d'un nom de schéma.
+ les index et les données de la partie TOAST.
</entry>
</row>
</tbody>
@@ -13628,7 +13631,9 @@
<literal>'main'</literal> ou laisser le second argument renvoit la taille du
morceau de données principal de la relation. Indiquer
<literal>'fsm'</literal> renvoit la taille de la carte des espaces libres
- (voir <xref linkend="storage-fsm"/>) associée à cette relation.
+ (voir <xref linkend="storage-fsm"/>) associée à cette relation. Indiquer
+ <literal>'vm'</literal> renvoit la taille de la carte de visibilité
+ (voir <xref linkend="storage-vm"/>) associée avec la relation.
</para>
<para>
Modified: traduc/trunk/postgresql/gist.xml
===================================================================
--- traduc/trunk/postgresql/gist.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/gist.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -108,60 +108,283 @@
<para>
Une classe d'opérateur d'index <acronym>GiST</acronym> doit fournir sept
- méthodes :
+ méthodes. Correctness of the index is ensured
+ by proper implementation of the <function>same</function>, <function>consistent</function>
+ and <function>union</function> methods, while efficiency (size and speed) of the
+ index will depend on the <function>penalty</function> and <function>picksplit</function>
+ methods.
+ The remaining two methods are <function>compress</function> and
+ <function>decompress</function>, which allow an index to have internal tree data of
+ a different type than the data it indexes. The leaves are to be of the
+ indexed data type, while the other tree nodes can be of any C struct (but
+ you still have to follow <productname>PostgreSQL</productname> datatype rules here,
+ see about <literal>varlena</literal> for variable sized data). If the tree's
+ internal data type exists at the SQL level, the <literal>STORAGE</literal> option
+ of the <command>CREATE OPERATOR CLASS</command> command can be used.
+
</para>
<variablelist>
<varlistentry>
- <term>consistent</term>
+ <term><function>consistent</function></term>
<listitem>
<para>
- Pour un prédicat <literal>p</literal> d'une page de l'arbre et une
- requête utilisateur <literal>q</literal> données, cette méthode retourne
- faux si <literal>p</literal> et <literal>q</literal> ne peuvent pas
- être simultanément vrais pour un élément de
- données particulier. Pour un vrai résultat, un drapeau
- <literal>recheck</literal> doit aussi être renvoyé ; ceci indique
- si le prédicat implique la requête (<literal>recheck</literal> = false)
- ou non (<literal>recheck</literal> = true).
+ Given an index entry <literal>p</literal> and a query value <literal>q</literal>,
+ this function determines whether the index entry is
+ <quote>consistent</quote> with the query; that is, could the predicate
+ <quote><replaceable>indexed_column</replaceable>
+ <replaceable>indexable_operator</replaceable> <literal>q</literal></quote> be true for
+ any row represented by the index entry? For a leaf index entry this is
+ equivalent to testing the indexable condition, while for an internal
+ tree node this determines whether it is necessary to scan the subtree
+ of the index represented by the tree node. When the result is
+ <literal>true</literal>, a <literal>recheck</literal> flag must also be returned.
+ This indicates whether the predicate is certainly true or only possibly
+ true. If <literal>recheck</literal> = <literal>false</literal> then the index has
+ tested the predicate condition exactly, whereas if <literal>recheck</literal>
+ = <literal>true</literal> the row is only a candidate match. In that case the
+ system will automatically evaluate the
+ <replaceable>indexable_operator</replaceable> against the actual row value to see
+ if it is really a match. This convention allows
+ <acronym>GiST</acronym> to support both lossless and lossy index
+ structures.
</para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_consistent(internal, data_type, smallint, oid, internal)
+RETURNS bool
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+Datum my_consistent(PG_FUNCTION_ARGS);
+PG_FUNCTION_INFO_V1(my_consistent);
+
+Datum
+my_consistent(PG_FUNCTION_ARGS)
+{
+ GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
+ data_type *query = PG_GETARG_DATA_TYPE_P(1);
+ StrategyNumber strategy = (StrategyNumber) PG_GETARG_UINT16(2);
+ /* Oid subtype = PG_GETARG_OID(3); */
+ bool *recheck = (bool *) PG_GETARG_POINTER(4);
+ data_type *key = DatumGetDataType(entry->key);
+ bool retval;
+
+ /*
+ * determine return value as a function of strategy, key and query.
+ *
+ * Use GIST_LEAF(entry) to know where you're called in the index tree,
+ * which comes handy when supporting the = operator for example (you could
+ * check for non empty union() in non-leaf nodes and equality in leaf
+ * nodes).
+ */
+
+ *recheck = true; /* or false if check is exact */
+
+ PG_RETURN_BOOL(retval);
+}
+</programlisting>
+
+ Here, <varname>key</varname> is an element in the index and <varname>query</varname>
+ the value being looked up in the index. The <literal>StrategyNumber</literal>
+ parameter indicates which operator of your operator class is being
+ applied — it matches one of the operator numbers in the
+ <command>CREATE OPERATOR CLASS</command> command. Depending on what operators
+ you have included in the class, the data type of <varname>query</varname> could
+ vary with the operator, but the above skeleton assumes it doesn't.
+ </para>
+
</listitem>
</varlistentry>
<varlistentry>
- <term>union</term>
+ <term><function>union</function></term>
<listitem>
<para>
- Cette méthode consolide les informations de l'arbre. Pour une liste
- d'entrées donnée, cette fonction produit un nouveau prédicat vrai pour
- toutes les entrées.
+ This method consolidates information in the tree. Given a set of
+ entries, this function generates a new index entry that represents
+ all the given entries.
</para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_union(internal, internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+Datum my_union(PG_FUNCTION_ARGS);
+PG_FUNCTION_INFO_V1(my_union);
+
+Datum
+my_union(PG_FUNCTION_ARGS)
+{
+ GistEntryVector *entryvec = (GistEntryVector *) PG_GETARG_POINTER(0);
+ GISTENTRY *ent = entryvec->vector;
+ data_type *out,
+ *tmp,
+ *old;
+ int numranges,
+ i = 0;
+
+ numranges = entryvec->n;
+ tmp = DatumGetDataType(ent[0].key);
+ out = tmp;
+
+ if (numranges == 1)
+ {
+ out = data_type_deep_copy(tmp);
+
+ PG_RETURN_DATA_TYPE_P(out);
+ }
+
+ for (i = 1; i < numranges; i++)
+ {
+ old = out;
+ tmp = DatumGetDataType(ent[i].key);
+ out = my_union_implementation(out, tmp);
+ }
+
+ PG_RETURN_DATA_TYPE_P(out);
+}
+</programlisting>
+ </para>
+
+ <para>
+ As you can see, in this skeleton we're dealing with a data type
+ where <literal>union(X, Y, Z) = union(union(X, Y), Z)</literal>. It's easy
+ enough to support data types where this is not the case, by
+ implementing the proper union algorithm in this
+ <acronym>GiST</acronym> support method.
+ </para>
+
+ <para>
+ The <function>union</function> implementation function should return a
+ pointer to newly <function>palloc()</function>ed memory. You can't just
+ return whatever the input is.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>compress</term>
+ <term><function>compress</function></term>
<listitem>
<para>
Convertit l'élément de données dans un format compatible avec
le stockage physique dans une page d'index.
</para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_compress(internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+Datum my_compress(PG_FUNCTION_ARGS);
+PG_FUNCTION_INFO_V1(my_compress);
+
+Datum
+my_compress(PG_FUNCTION_ARGS)
+{
+ GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
+ GISTENTRY *retval;
+
+ if (entry->leafkey)
+ {
+ /* replace entry->key with a compressed version */
+ compressed_data_type *compressed_data = palloc(sizeof(compressed_data_type));
+
+ /* fill *compressed_data from entry->key ... */
+
+ retval = palloc(sizeof(GISTENTRY));
+ gistentryinit(*retval, PointerGetDatum(compressed_data),
+ entry->rel, entry->page, entry->offset, FALSE);
+ }
+ else
+ {
+ /* typically we needn't do anything with non-leaf entries */
+ retval = entry;
+ }
+
+ PG_RETURN_POINTER(retval);
+}
+</programlisting>
+ </para>
+
+ <para>
+ You have to adapt <replaceable>compressed_data_type</replaceable> to the specific
+ type you're converting to in order to compress your leaf nodes, of
+ course.
+ </para>
+
+ <para>
+ Depending on your needs, you could also need to care about
+ compressing <literal>NULL</literal> values in there, storing for example
+ <literal>(Datum) 0</literal> like <literal>gist_circle_compress</literal> does.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>decompress</term>
+ <term><function>decompress</function></term>
<listitem>
<para>
L'inverse de la fonction <function>compress</function>. Convertit la
représentation de l'élément de donnée en un format manipulable par la base
de données.
</para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_decompress(internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+Datum my_decompress(PG_FUNCTION_ARGS);
+PG_FUNCTION_INFO_V1(my_decompress);
+
+Datum
+my_decompress(PG_FUNCTION_ARGS)
+{
+ PG_RETURN_POINTER(PG_GETARG_POINTER(0));
+}
+</programlisting>
+
+ The above skeleton is suitable for the case where no decompression
+ is needed.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>penalty</term>
+ <term><function>penalty</function></term>
<listitem>
<para>
Renvoie une valeur indiquant le <quote>coût</quote> d'insertion
@@ -169,26 +392,195 @@
éléments seront insérés dans l'ordre des pénalités moindres
(<function>penalty</function>) de l'arbre.
</para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_penalty(internal, internal, internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT; -- in some cases penalty functions need not be strict
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+Datum my_penalty(PG_FUNCTION_ARGS);
+PG_FUNCTION_INFO_V1(my_penalty);
+
+Datum
+my_penalty(PG_FUNCTION_ARGS)
+{
+ GISTENTRY *origentry = (GISTENTRY *) PG_GETARG_POINTER(0);
+ GISTENTRY *newentry = (GISTENTRY *) PG_GETARG_POINTER(1);
+ float *penalty = (float *) PG_GETARG_POINTER(2);
+ data_type *orig = DatumGetDataType(origentry->key);
+ data_type *new = DatumGetDataType(newentry->key);
+
+ *penalty = my_penalty_implementation(orig, new);
+ PG_RETURN_POINTER(penalty);
+}
+</programlisting>
+ </para>
+
+ <para>
+ The <function>penalty</function> function is crucial to good performance of
+ the index. It'll get used at insertion time to determine which branch
+ to follow when choosing where to add the new entry in the tree. At
+ query time, the more balanced the index, the quicker the lookup.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>picksplit</term>
+ <term><function>picksplit</function></term>
<listitem>
<para>
- Quand une coupure de page est nécessaire, cette fonction décide des
- entrées qui restent sur l'ancienne page et de celles
- déplacées sur la nouvelle.
+ When an index page split is necessary, this function decides which
+ entries on the page are to stay on the old page, and which are to move
+ to the new page.
</para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_picksplit(internal, internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+Datum my_picksplit(PG_FUNCTION_ARGS);
+PG_FUNCTION_INFO_V1(my_picksplit);
+
+Datum
+my_picksplit(PG_FUNCTION_ARGS)
+{
+ GistEntryVector *entryvec = (GistEntryVector *) PG_GETARG_POINTER(0);
+ OffsetNumber maxoff = entryvec->n - 1;
+ GISTENTRY *ent = entryvec->vector;
+ GIST_SPLITVEC *v = (GIST_SPLITVEC *) PG_GETARG_POINTER(1);
+ int i,
+ nbytes;
+ OffsetNumber *left,
+ *right;
+ data_type *tmp_union;
+ data_type *unionL;
+ data_type *unionR;
+ GISTENTRY **raw_entryvec;
+
+ maxoff = entryvec->n - 1;
+ nbytes = (maxoff + 1) * sizeof(OffsetNumber);
+
+ v->spl_left = (OffsetNumber *) palloc(nbytes);
+ left = v->spl_left;
+ v->spl_nleft = 0;
+
+ v->spl_right = (OffsetNumber *) palloc(nbytes);
+ right = v->spl_right;
+ v->spl_nright = 0;
+
+ unionL = NULL;
+ unionR = NULL;
+
+ /* Initialize the raw entry vector. */
+ raw_entryvec = (GISTENTRY **) malloc(entryvec->n * sizeof(void *));
+ for (i = FirstOffsetNumber; i <= maxoff; i = OffsetNumberNext(i))
+ raw_entryvec[i] = &(entryvec->vector[i]);
+
+ for (i = FirstOffsetNumber; i <= maxoff; i = OffsetNumberNext(i))
+ {
+ int real_index = raw_entryvec[i] - entryvec->vector;
+
+ tmp_union = DatumGetDataType(entryvec->vector[real_index].key);
+ Assert(tmp_union != NULL);
+
+ /*
+ * Choose where to put the index entries and update unionL and unionR
+ * accordingly. Append the entries to either v_spl_left or
+ * v_spl_right, and care about the counters.
+ */
+
+ if (my_choice_is_left(unionL, curl, unionR, curr))
+ {
+ if (unionL == NULL)
+ unionL = tmp_union;
+ else
+ unionL = my_union_implementation(unionL, tmp_union);
+
+ *left = real_index;
+ ++left;
+ ++(v->spl_nleft);
+ }
+ else
+ {
+ /*
+ * Same on the right
+ */
+ }
+ }
+
+ v->spl_ldatum = DataTypeGetDatum(unionL);
+ v->spl_rdatum = DataTypeGetDatum(unionR);
+ PG_RETURN_POINTER(v);
+}
+</programlisting>
+ </para>
+
+ <para>
+ Like <function>penalty</function>, the <function>picksplit</function> function
+ is crucial to good performance of the index. Designing suitable
+ <function>penalty</function> and <function>picksplit</function> implementations
+ is where the challenge of implementing well-performing
+ <acronym>GiST</acronym> indexes lies.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term>same</term>
+ <term><function>same</function></term>
<listitem>
<para>
- Renvoie vrai si deux entrées sont identiques, faux autrement.
+ Returns true if two index entries are identical, false otherwise.
</para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_same(internal, internal, internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+Datum my_same(PG_FUNCTION_ARGS);
+PG_FUNCTION_INFO_V1(my_same);
+
+Datum
+my_same(PG_FUNCTION_ARGS)
+{
+ prefix_range *v1 = PG_GETARG_PREFIX_RANGE_P(0);
+ prefix_range *v2 = PG_GETARG_PREFIX_RANGE_P(1);
+ bool *result = (bool *) PG_GETARG_POINTER(2);
+
+ *result = my_eq(v1, v2);
+ PG_RETURN_POINTER(result);
+}
+</programlisting>
+
+ For historical reasons, the <function>same</function> function doesn't
+ just return a boolean result; instead it has to store the flag
+ at the location indicated by the third argument.
+ </para>
</listitem>
</varlistentry>
Modified: traduc/trunk/postgresql/indices.xml
===================================================================
--- traduc/trunk/postgresql/indices.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/indices.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -37,7 +37,7 @@
<structname>test1</structname>, et que seules quelques lignes
correspondent à la requête (peut-être même zéro ou une seule), alors,
clairement, la méthode n'est pas efficace.
- Mais si le système maintient un index sur la colonne
+ Mais si le système doit maintenir un index sur la colonne
<structfield>id</structfield>, alors il peut utiliser une manière
beaucoup plus efficace pour trouver les lignes recherchées.
Il se peut qu'il n'ait ainsi qu'à parcourir quelques niveaux d'un arbre de
@@ -456,7 +456,7 @@
Les index d'ordre différent de celui par défaut sont visiblement une
fonctionnalité très spécialisée, mais ils peuvent parfois être à l'origine
d'accélérations spectaculaires des performances sur certaines requêtes.
- L'intérêt de créer un tel index dépend
+ L'intérêt de maintenir un tel index dépend
de la fréquence des requêtes qui nécessitent un tri particulier.
</para>
</sect1>
@@ -681,10 +681,10 @@
<para>
Une raison majeure à l'utilisation d'index partiels est d'éviter
d'indexer les valeurs courantes. Puisqu'une requête qui recherche une
- valeur courante (qui correspond à plus de quelques
- pourcents de toutes les lignes) n'utilise, de toute façon, pas cet index, il ne sert
- à rien de garder ces lignes dans l'index. Un index partiel réduit la taille de l'index,
- ce qui accélère les requêtes qui l'utilisent. Cela accélère aussi nombre
+ valeur courante (qui correspond à plus de quelques pourcents de toutes
+ les lignes) n'utilise, de toute façon, pas cet index, il ne sert à rien
+ de garder ces lignes dans l'index. Cela réduit la taille de l'index,
+ ce qui accélèrera les requêtes qui l'utilisent. Cela accélère aussi nombre
d'opérations de mise à jour de la table, car l'index n'a pas à être
mis à jour à chaque fois. L'<xref linkend="indexes-partial-ex1"/> montre une
application possible de cette idée.
Modified: traduc/trunk/postgresql/installation.xml
===================================================================
--- traduc/trunk/postgresql/installation.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/installation.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -416,10 +416,9 @@
<para>
Sur les systèmes qui lancent <productname>PostgreSQL</productname> au démarrage, il y
a probablement un fichier de démarrage qui peut faire la même chose. Par
- exemple, sur un système <systemitem class="osname">Red Hat Linux</systemitem>, la
- commande
+ exemple, sur un système <systemitem class="osname">Red Hat Linux</systemitem>, cette
+ commande doit fonctionner :
<screen><userinput>/etc/rc.d/init.d/postgresql stop</userinput></screen>
- doit fonctionner.
</para>
</step>
@@ -1675,7 +1674,7 @@
</indexterm>
<para>
- Sur plusieurs systèmes qui utilisent les bibliothèques partagées (ce que font
+ Sur certains systèmes qui utilisent les bibliothèques partagées (ce que font
de nombreux systèmes), vous avez besoin de leurs spécifier comment trouver
les nouvelles bibliothèques partagées. Les systèmes sur lesquels ce
<emphasis>n'est</emphasis> pas nécessaire comprennent <systemitem
@@ -2034,8 +2033,9 @@
</indexterm>
<para>
- PostgreSQL sur AIX fonctionne, mais réussir à l'installer correctement peut
- s'avérer difficile. AIX 4.3 et 5.3 sont tous les deux supportés en théorie.
+ PostgreSQL fonctionne sur AIX, mais réussir à l'installer correctement peut
+ s'avérer difficile. Les versions AIX de la 4.3.3 à la 6.1 sont considérées
+ comme supportées en théorie.
Vous pouvez utiliser GCC ou le compilateur natif IBM xlc. En général,
utiliser des versions récentes d'AIX et PostgreSQL rend la tâche plus simple.
Vérifiez la ferme de compilation pour avoir des informations à jour sur
@@ -2044,7 +2044,7 @@
<para>
Utilisez les options suivantes de <command>configure</command> en plus
- des vôtres si vous avez Readline ou libz à ces endroits :
+ des vôtres si vous avez installé Readline ou libz à ces endroits :
<literal>--with-includes=/usr/local/include
--with-libraries=/usr/local/lib</literal>.
</para>
@@ -2066,18 +2066,56 @@
<ulink url="http://www.han.de/~jum/aix/ldd.c"></ulink>.
</para>
- <sect3>
- <title>AIX 4.3.2</title>
+ <para>
+ <xref linkend="AIX-fixlevels"/> indique les niveaux minimum de correctifs
+ demandés pour les différentes versions d'AIX. Pour vérifier votre niveau
+ de correctif, utilisez <command>oslevel -r</command> de AIX 4.3.3 à
+ AIX 5.2 ML 7, et <command>oslevel -s</command> pour les versions
+ ultérieures.
+ </para>
- <para>
- Sur AIX 4.3.2, vous avez besoin de <filename>libm.a</filename> qui est dans
- le fileset <literal>bos.adt.libm</literal>. Essayez la commande suivante :
-<screen>
-$ lslpp -l bos.adt.libm
-</screen>
- </para>
- </sect3>
+ <table id="AIX-fixlevels">
+ <title>
+ Niveaux minimums recommandés de correctifs pour <systemitem class="osname">AIX</systemitem>
+ </title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Version d'AIX</entry>
+ <entry>Niveau du correctif</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry>AIX 4.3.3</entry>
+ <entry>Maintenance Level 11 + post ML11 bundle</entry>
+ </row>
+
+ <row>
+ <entry>AIX 5.1</entry>
+ <entry>Maintenance Level 9 + post ML9 bundle</entry>
+ </row>
+
+ <row>
+ <entry>AIX 5.2</entry>
+ <entry>Technology Level 10 Service Pack 3</entry>
+ </row>
+
+ <row>
+ <entry>AIX 5.3</entry>
+ <entry>Technology Level 7</entry>
+ </row>
+
+ <row>
+ <entry>AIX 6.1</entry>
+ <entry>Base Level</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
<sect3>
<title>Problèmes avec GCC</title>
@@ -2114,10 +2152,10 @@
<para>
Le problème a été rapporté à IBM, et est enregistré en tant que rapport
de bogue PMR29657. Si vous mettez à jour vers le niveau de maintenance
- 5300-03, le correctif sera inclus. Utilisez la commande
- <literal>oslevel -r</literal> pour déterminer votre niveau de maintenance
- courant. Une résolution immédiate est de corriger <symbol>_SS_MAXSIZE</symbol>
- à 1025 dans <filename>/usr/include/sys/socket.h</filename>.
+ 5300-03 et ultérieur, le correctif sera inclus. Une résolution immédiate
+ est de corriger <symbol>_SS_MAXSIZE</symbol> à 1025 dans
+ <filename>/usr/include/sys/socket.h</filename>. Dans tous les cas,
+ recompilez PostgreSQL une fois que vous avez l'en-tête corrigé.
</para>
</sect3>
@@ -2129,8 +2167,8 @@
pour analyser les adresses IP dans <varname>listen_addresses</varname> et
dans <filename>pg_hba.conf</filename>, etc. Les anciennes versions d'AIX
ont quelques bogues dans cette fonction. Si vous avez des problèmes relatifs
- à ces paramètres, la mise à jour de votre version d'AIX pourrait corriger
- cela.
+ à ces paramètres, la mise à jour vers le niveau de correctif approprié
+ indiqué dans <xref linkend="AIX-fixlevels"/> pourrait se charger de cela.
</para>
<!-- http://archives.postgresql.org/message-id/6064jt6cfm.fsf_-_@dba2.int.libertyrms.com -->
Modified: traduc/trunk/postgresql/maintenance.xml
===================================================================
--- traduc/trunk/postgresql/maintenance.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/maintenance.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -631,7 +631,7 @@
<para>
Les tables dont la valeur de <structfield>relfrozenxid</structfield> est
- plus importante que <varname>autovacuum_freeze_max_age</varname> sont
+ plus importante que <xref linkend="guc-autovacuum-freeze-max-age"/> sont
toujours l'objet d'un VACUUM (cela s'applique aux tables dont le 'freeze max age'
a été modifié par les paramètres de stockage ; voyez plus bas).
Sinon, si le nombre de lignes obsolètes
Modified: traduc/trunk/postgresql/mvcc.xml
===================================================================
--- traduc/trunk/postgresql/mvcc.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/mvcc.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -385,15 +385,15 @@
<command>SELECT</command> voit seulement les données validées avant le début
de la transaction ; elle ne voit jamais les données non validées et les
modifications validées lors de l'exécution de la transaction par des
- transactions concurrentes (néanmoins, le <command>SELECT</command> voit
+ transactions concurrentes (néanmoins, la requête voit
bien les effets des mises à jour précédentes exécutées à l'intérieur de sa
propre transaction même si elles ne sont pas encore validées). C'est
- différent du niveau Read Commited dans la mesure où <command>SELECT</command>,
+ différent du niveau Read Commited dans la mesure où une requête,
dans une transaction sérialisable, voit une image du début de la transaction
et non pas du début de la requête en cours à l'intérieur de la transaction.
Du coup, les commandes <command>SELECT</command> successives à l'intérieur
d'une <emphasis>seule</emphasis> transaction voient toujours les mêmes données,
- c'est-à-dire qu'elles ne voient jamais les modifications faites par les
+ c'est-à-dire qu'elles ne voient jamais les modifications faites par les autres
transactions qui ont validé après le début de leur propre transaction (ce
comportement peut être idéal pour les applications de création de rapports.)
</para>
@@ -682,9 +682,10 @@
</term>
<listitem>
<para>
- En conflit avec les modes de verrous sauf <literal>ACCESS
- SHARE</literal>, <literal>ROW SHARE</literal> et <literal>SHARE</literal>
- (il n'entre pas en conflit avec lui-même). Ce mode protège une table
+ En conflit avec les modes de verrous <literal>ROW EXCLUSIVE</literal>,
+ <literal>SHARE UPDATE EXCLUSIVE</literal>, <literal>SHARE ROW
+ EXCLUSIVE</literal>, <literal>EXCLUSIVE</literal> et
+ <literal>ACCESS EXCLUSIVE</literal>. Ce mode protège une table
contre les modifications simultanées des données.
</para>
@@ -700,8 +701,11 @@
</term>
<listitem>
<para>
- En conflit avec tous les modes de verrous sauf <literal>ACCESS
- SHARE</literal> et <literal>ROW SHARE</literal>.
+ En conflit avec les modes de verrous <literal>ROW EXCLUSIVE</literal>,
+ <literal>SHARE UPDATE EXCLUSIVE</literal>,
+ <literal>SHARE</literal>, <literal>SHARE ROW
+ EXCLUSIVE</literal>, <literal>EXCLUSIVE</literal> et
+ <literal>ACCESS EXCLUSIVE</literal>.
</para>
<para>
@@ -717,11 +721,14 @@
</term>
<listitem>
<para>
- En conflit avec tous les modes de verrous sauf <literal>ACCESS
- SHARE</literal>. Ce mode autorise uniquement les verrous <literal>ACCESS
- SHARE</literal> concurrents, c'est-à-dire que seules les lectures à
- partir de la table peuvent être effectuées en parallèle avec une transaction
- contenant ce mode de verrouillage.
+ En conflit avec les modes de verrous <literal>ROW SHARE</literal>,
+ <literal>ROW EXCLUSIVE</literal>, <literal>SHARE UPDATE
+ EXCLUSIVE</literal>, <literal>SHARE</literal>, <literal>SHARE
+ ROW EXCLUSIVE</literal>, <literal>EXCLUSIVE</literal> et
+ <literal>ACCESS EXCLUSIVE</literal>. Ce mode autorise uniquement les
+ verrous <literal>ACCESS SHARE</literal> concurrents, c'est-à-dire que
+ seules les lectures à partir de la table peuvent être effectuées en
+ parallèle avec une transaction contenant ce mode de verrouillage.
</para>
<para>
@@ -739,7 +746,12 @@
</term>
<listitem>
<para>
- Entre en conflit avec tous les modes.
+ Entre en conflit avec tous les modes (<literal>ACCESS
+ SHARE</literal>, <literal>ROW SHARE</literal>, <literal>ROW
+ EXCLUSIVE</literal>, <literal>SHARE UPDATE
+ EXCLUSIVE</literal>, <literal>SHARE</literal>, <literal>SHARE
+ ROW EXCLUSIVE</literal>, <literal>EXCLUSIVE</literal> et
+ <literal>ACCESS EXCLUSIVE</literal>).
Ce mode garantit que le détenteur est la seule transaction à accéder à
la table de quelque façon que ce soit.
</para>
@@ -1119,7 +1131,7 @@
d'actualité au moment où elle est renvoyée (c'est-à-dire, quelque temps après
que la requête <command>SELECT</command> ait commencé). La ligne pourrait
avoir été modifiée ou supprimée par une transaction validée entretemps.
- Même si la ligne est encore valide <emphasis>maintenant</emphasis>, elle
+ Même si la ligne est encore valide <quote>maintenant</quote>, elle
pourrait être modifiée ou supprimée avant que notre transaction ne soit
validée ou annulée.
</para>
Modified: traduc/trunk/postgresql/perform.xml
===================================================================
--- traduc/trunk/postgresql/perform.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/perform.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -52,7 +52,9 @@
d'index bitmap. Si la requête requiert des jointures, agrégations, tris
ou d'autres opérations sur les lignes brites, ce seront des nœuds
supplémentaires au-dessus des nœuds de parcours pour réaliser ces
- opérations. D'autres types de nœuds sont aussi supportés. La sortie
+ opérations. Encore une fois, il existe plus d'une façon de réaliser ces
+ opérations, donc différents types de nœuds peuvent aussi apparaître
+ ici. La sortie
d'<command>EXPLAIN</command> comprend une ligne pour chaque nœud dans
l'arbre du plan, montrant le type de nœud basique avec les estimations
de coût que le planificateur a fait pour l'exécution de ce nœud du
@@ -135,14 +137,13 @@
que le coût reflète seulement les éléments d'importance pour le
planificateur. En particulier, le coût ne considère pas le temps
dépensé dans la transmission des lignes de résultat au client, ce qui
- pourrait être un facteur important dans le temps total passé ; mais
+ pourrait être un facteur important dans le temps réel passé ; mais
le planificateur l'ignore parce qu'il ne peut pas le changer en modifiant
le plan (chaque plan correct sortira le même ensemble de lignes).
</para>
<para>
- La valeur <literal>rows=</literal> de l'<command>EXPLAIN</command> est un
- peu difficile car il ne s'agit
+ La valeur <literal>rows</literal> est un peu difficile car il ne s'agit
<emphasis>pas</emphasis> du nombre de lignes traitées ou parcourues par le
plan de nœuds. C'est habituellement moins, reflétant la sélectivité
estimée des conditions de la clause <literal>WHERE</literal> qui sont appliquées au
@@ -200,7 +201,7 @@
<para>
Le nombre réel de lignes que cette requête sélectionnera est 7000 mais
- l'estimation <literal>rows=</literal> est approximative. Si vous tentez
+ l'estimation <literal>rows</literal> est approximative. Si vous tentez
de dupliquer cette
expérience, vous obtiendrez probablement une estimation légèrement
différente ; de plus, elle changera après chaque commande
@@ -238,7 +239,7 @@
<para>
Si la condition <literal>WHERE</literal> est assez sélective, le planificateur
pourrait basculer vers un plan de parcours d'index
- <emphasis>simple</emphasis> :
+ <quote>simple</quote> :
<programlisting>EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 3;
@@ -421,11 +422,11 @@
Dans certains plans de requête, il est possible qu'un nœud de
sous-plan soit exécuté plus d'une fois. Par exemple, le parcours d'index
interne est exécuté une fois par ligne externe dans le plan de boucle
- imbriquée ci-dessus. Dans de tels cas, la valeur <quote>loops</quote>
+ imbriquée ci-dessus. Dans de tels cas, la valeur <literal>loops</literal>
renvoie le nombre total d'exécution du nœud, et le temps réel et les
valeurs des lignes affichées sont une moyenne par exécution. Ceci est fait
pour que les nombres soient comparables avec la façon dont les estimations
- de coûts sont affichées. Multipliez par la valeur de <quote>loops</quote>
+ de coûts sont affichées. Multipliez par la valeur de <literal>loops</literal>
pour obtenir le temps total réellement passé dans le nœud.
</para>
@@ -784,7 +785,7 @@
</indexterm>
<para>
- Lors d'<command>INSERT</command>, désactivez la validation automatique et faites
+ Lors d'<command>INSERT</command> multiples, désactivez la validation automatique et faites
une seule validation à la
fin (en SQL, ceci signifie de lancer <command>BEGIN</command> au début et
<command>COMMIT</command> à la fin. Quelques bibliothèques client pourraient
Modified: traduc/trunk/postgresql/plpgsql.xml
===================================================================
--- traduc/trunk/postgresql/plpgsql.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/plpgsql.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -2416,7 +2416,7 @@
<note>
<para>
- Les curseurs liés peuvent aussi être utilisés sans les ouvrir
+ Les variables des curseurs liés peuvent aussi être utilisés sans les ouvrir
explicitement, via l'instruction <command>FOR</command> décrite dans
<xref linkend="plpgsql-cursor-for-loop"/>.
</para>
@@ -2425,14 +2425,14 @@
<sect3>
<title><command>OPEN FOR</command> <replaceable>requête</replaceable></title>
-<synopsis>OPEN <replaceable>curseur_nonlie</replaceable> <optional> <optional> NO </optional> SCROLL </optional> FOR <replaceable>requete</replaceable>;
+<synopsis>OPEN <replaceable>var_curseur_nonlie</replaceable> <optional> <optional> NO </optional> SCROLL </optional> FOR <replaceable>requete</replaceable>;
</synopsis>
<para>
La variable curseur est ouverte et reçoit la requête spécifiée à
exécuter. Le curseur ne peut pas être déjà ouvert, et il doit avoir
- été déclaré comme curseur non lié (c'est-à-dire comme une simple
- variable <type>refcursor</type>). La requête doit être un
+ été déclaré comme une variable de curseur non lié (c'est-à-dire comme
+ une simple variable <type>refcursor</type>). La requête doit être un
<command>SELECT</command> ou quelque chose d'autre qui renvoie des
lignes (comme <command>EXPLAIN</command>). La requête est traitée de la même
façon que les autres commandes SQL dans <application>PL/pgSQL</application> :
@@ -2456,12 +2456,13 @@
<sect3>
<title><command>OPEN FOR EXECUTE</command></title>
-<synopsis>OPEN <replaceable>curseur_nonlie</replaceable> <optional> <optional> NO </optional> SCROLL </optional> FOR EXECUTE <replaceable class="command">requete</replaceable>;
+<synopsis>OPEN <replaceable>var_curseur_nonlie</replaceable> <optional> <optional> NO </optional> SCROLL </optional> FOR EXECUTE <replaceable class="command">requete</replaceable>;
</synopsis>
<para>
La variable curseur est ouverte et reçoit la requête spécifiée à exécuter.
Le curseur ne peut pas être déjà ouvert et il doit avoir été déclaré comme
+ une variable de
curseur non lié (c'est-à-dire comme une simple variable <type>refcursor</type>).
La requête est spécifiée comme une expression chaîne de la même façon que
dans une commande <command>EXECUTE</command>. Comme d'habitude, ceci donne
@@ -2483,7 +2484,7 @@
<sect3>
<title>Ouverture d'un curseur lié</title>
-<synopsis>OPEN <replaceable>curseur_lié</replaceable> <optional> ( <replaceable>arguments</replaceable> ) </optional>;
+<synopsis>OPEN <replaceable>var_curseur_lié</replaceable> <optional> ( <replaceable>arguments</replaceable> ) </optional>;
</synopsis>
<para>
@@ -2804,7 +2805,7 @@
<synopsis>
<optional> <<<replaceable>label</replaceable>>> </optional>
-FOR <replaceable>var_record</replaceable> IN <replaceable>curseur_lié</replaceable> <optional> ( <replaceable>valeurs_argument</replaceable> ) </optional> LOOP
+FOR <replaceable>var_record</replaceable> IN <replaceable>var_curseur_lié</replaceable> <optional> ( <replaceable>valeurs_argument</replaceable> ) </optional> LOOP
<replaceable>instructions</replaceable>
END LOOP <optional> <replaceable>label</replaceable> </optional>;
</synopsis>
Modified: traduc/trunk/postgresql/queries.xml
===================================================================
--- traduc/trunk/postgresql/queries.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/queries.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -175,11 +175,12 @@
<synopsis><replaceable>T1</replaceable> CROSS JOIN <replaceable>T2</replaceable></synopsis>
<para>
- Produit tout combinaison possible de lignes provenant de
+ Pour chaque combinaison possible de lignes provenant de
<replaceable>T1</replaceable> et <replaceable>T2</replaceable>
- (c'est-à-dire un produit cartésien), avec des colonnes en sortie
- consistant en toutes les colonnes de <replaceable>T1</replaceable>
- suivies par toutes les colonnes de <replaceable>T2</replaceable>.
+ (c'est-à-dire un produit cartésien), la table jointe contiendra
+ une ligne disposant de toutes les colonnes de
+ <replaceable>T1</replaceable> suivies par toutes les colonnes de
+ <replaceable>T2</replaceable>.
Si les tables ont respectivement N et M lignes, la table jointe en
aura N * M.
</para>
@@ -325,7 +326,7 @@
<para>
Tout d'abord, une jointure interne est réalisée. Puis, pour chaque
ligne de T1 qui ne satisfait pas la condition de jointure avec
- les lignes de T2, une ligne est ajoutée avec des valeurs
+ les lignes de T2, une ligne jointe est ajoutée avec des valeurs
NULL dans les colonnes de T2. Du coup, la table jointe a toujours au moins
une ligne pour chaque ligne de T1 quelque soient les conditions.
</para>
@@ -357,7 +358,7 @@
<para>
Tout d'abord, une jointure interne est réalisée. Puis, pour chaque
ligne de T2 qui ne satisfait pas la condition de jointure avec les
- lignes de T1, une ligne est ajoutée avec des valeurs NULL
+ lignes de T1, une ligne jointe est ajoutée avec des valeurs NULL
dans les colonnes de T1. C'est l'inverse d'une jointure gauche :
la table résultante aura toujours une ligne pour chaque ligne de T2 quelque
soient les conditions.
@@ -372,9 +373,9 @@
<para>
Tout d'abord, une jointure interne est réalisée. Puis, pour chaque
ligne de T1 qui ne satisfait pas la condition de jointure avec les
- lignes de T2, une ligne est ajoutée avec des valeurs NULL dans
+ lignes de T2, une ligne jointe est ajoutée avec des valeurs NULL dans
les colonnes de T2. De plus, pour chaque ligne de T2 qui ne satisfait
- pas la condition de jointure avec les lignes de T1, une ligne
+ pas la condition de jointure avec les lignes de T1, une ligne jointe
est ajoutée avec des valeurs NULL dans les colonnes de T1.
</para>
</listitem>
@@ -696,8 +697,7 @@
Dans certains cas, il est utile de définir des fonctions de table pouvant
renvoyer des ensembles de colonnes différentes suivant la façon dont elles
sont appelées. Pour supporter ceci, la fonction de table est déclarée comme
- renvoyant le pseudotype <type>record</type>, plutôt que <literal>SET
- OF</literal>. Quand une telle fonction est
+ renvoyant le pseudotype <type>record</type>. Quand une telle fonction est
utilisée dans une requête, la structure de ligne attendue doit être
spécifiée dans la requête elle-même, de façon à ce que le système sache
comment analyser et planifier la requête. Considérez cet exemple :
@@ -757,7 +757,7 @@
même si cela fait partie du standard SQL.
Pour les jointures externes, il n'y a pas d'autres choix : elles
doivent être faites dans la clause <literal>FROM</literal>. La clause
- <literal>ON</literal>/<literal>USING</literal> d'une jointure externe n'est
+ <literal>ON</literal> ou <literal>USING</literal> d'une jointure externe n'est
<emphasis>pas</emphasis> équivalente à une condition <literal>WHERE</literal> parce
qu'elle détermine l'ajout de lignes (pour les lignes qui ne correspondent
pas en entrée) ainsi que pour la suppression de lignes dans le résultat
@@ -778,7 +778,7 @@
SELECT ... FROM fdt WHERE c1 BETWEEN (SELECT c3 FROM t2 WHERE c2 = fdt.c1 + 10) AND 100
SELECT ... FROM fdt WHERE EXISTS (SELECT c1 FROM t2 WHERE c2 > fdt.c1)</programlisting>
- <literal>fdt</literal> est la table utilisée dans la clause
+ <literal>fdt</literal> est la table dérivée dans la clause
<literal>FROM</literal>. Les lignes qui ne correspondent pas à la condition de
recherche de la clause <literal>WHERE</literal> sont éliminées de la table
<literal>fdt</literal>. Notez l'utilisation de sous-requêtes scalaires en
@@ -856,8 +856,9 @@
<para>
En général, si une table est groupée, les colonnes qui ne sont pas
- identiques dans le regroupement ne peuvent pas être référencées sauf dans les
- expressions d'agrégats. Voici un exemple d'expressions d'agrégat :
+ listées dans le <literal>GROUP BY</literal> ne peuvent pas être référencées
+ sauf dans les expressions d'agrégats. Voici un exemple d'expressions
+ d'agrégat :
<screen><prompt>=></prompt> <userinput>SELECT x, sum(y) FROM test1 GROUP BY x;</userinput>
x | sum
---+-----
@@ -1126,7 +1127,7 @@
<para>
Le nom des colonnes en sortie est différent ici de ce qui est fait dans la
clause <literal>FROM</literal> (voir la <xref linkend="queries-table-aliases"/>).
- Il est possible de renommer deux fois la même colonne mais le nom choisi
+ Il est possible de renommer deux fois la même colonne mais le nom affecté
dans la liste de sélection est celui qui sera passé.
</para>
</note>
@@ -1324,11 +1325,11 @@
<para>
Les options <literal>NULLS FIRST</literal> et <literal>NULLS LAST</literal>
sont utilisées pour déterminer si les valeurs NULL apparaissent avant ou
- après les valeurs non NULL après un tri. Le comportement par défaut est de
- trier les valeurs NULL comme si elles étaient plus grosses que les autres
- valeurs (<literal>NULLS FIRST</literal>), sauf dans un tri
- <literal>DESC</literal> où <literal>NULLS LAST</literal> est le comportement
- par défaut.
+ après les valeurs non NULL après un tri. Par défaut, les valeurs NULL sont
+ triées comme si elles étaient plus grandes que toute valeur non NULL.
+ Autrement dit, <literal>NULLS FIRST</literal> est la valeur par défaut pour
+ l'ordre descendant (<literal>DESC</literal>) et <literal>NULLS LAST</literal>
+ est la valeur utilisée sinon.
</para>
<para>
@@ -1449,7 +1450,7 @@
<synopsis>
VALUES ( <replaceable class="parameter">expression</replaceable> [, ...] ) [, ...]
</synopsis>
- Chaque liste d'expressions entre parenthèses génère une ligne dans l'expression de la table.
+ Chaque liste d'expressions entre parenthèses génère une ligne dans la table.
Les listes doivent toutes avoir le même nombre d'éléments (c'est-à-dire une
liste de colonnes dans la table), et les entrées correspondantes dans chaque
liste doivent avoir des types compatibles. Le type réel affecté à chaque colonne
Modified: traduc/trunk/postgresql/query.xml
===================================================================
--- traduc/trunk/postgresql/query.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/query.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -158,7 +158,7 @@
<type>real</type> est un type pour les nombres décimaux
en simple précision. <type>date</type> devrait s'expliquer de lui-même
(oui, la colonne de type <type>date</type> est aussi nommée
- <literal>date</literal> ; cela peut être commode ou porter à
+ <structfield>date</structfield> ; cela peut être commode ou porter à
confusion, à vous de choisir).
</para>
@@ -174,7 +174,7 @@
<productname>PostgreSQL</productname> peut être personnalisé avec
un nombre arbitraire de types de données définis par
l'utilisateur. En conséquence, les noms des types ne sont pas des
- mots-clé spéciaux dans la syntaxe sauf lorsqu'il est requis de supporter
+ mots-clé dans la syntaxe sauf lorsqu'il est requis de supporter
des cas particuliers dans la norme <acronym>SQL</acronym>.
</para>
@@ -288,7 +288,7 @@
(la partie qui liste les tables à partir desquelles les données
seront retrouvées) et une qualification optionnelle (la partie qui
spécifie les restrictions). Par exemple, pour retrouver toutes
- les lignes de la table <classname>temps</classname>, saisissez :
+ les lignes de la table <structname>temps</structname>, saisissez :
<programlisting>SELECT * FROM temps;</programlisting>
Ici, <literal>*</literal> est un raccourci pour <quote>toutes les
colonnes</quote>.
@@ -425,9 +425,10 @@
lignes de la table soient traitées en même temps. Une requête qui
consulte plusieurs lignes de la même ou de différentes tables en
même temps est appelée requête de <firstterm>jointure</firstterm>.
- Comme exemple, supposez que vous souhaitez lister toutes les
- entrées de la table <literal>temps</literal> avec la colonne des noms de
- toutes les lignes de la table <literal>villes</literal> et que vous
+ Comme exemple, supposez que vous souhaitez comparer la colonne
+ <structfield>ville</structfield> de chaque ligne de la table
+ <structname>temps</structname> avec la colonne <structfield>nom</structfield>
+ de toutes les lignes de la table <structname>villes</structname> et que vous
choisissez les paires de lignes où ces valeurs correspondent.
<note>
<para>
@@ -458,9 +459,9 @@
<para>
Il n'y a pas de lignes pour la ville de Hayward dans le résultat. C'est
parce qu'il n'y a aucune entrée correspondante
- dans la table <classname>villes</classname> pour Hayward, donc
+ dans la table <structname>villes</structname> pour Hayward, donc
la jointure ignore les lignes n'ayant pas de correspondance
- avec la table <literal>temps</literal>. Nous verrons rapidement comment cela
+ avec la table <structname>temps</structname>. Nous verrons rapidement comment cela
peut être résolu.
</para>
</listitem>
@@ -468,8 +469,8 @@
<listitem>
<para>
Il y a deux colonnes contenant le nom des villes. C'est
- correct car les colonnes des tables
- <classname>temps</classname> et <classname>villes</classname>
+ correct car les listes des colonnes des tables
+ <structname>temps</structname> et <structname>villes</structname>
sont concaténées. En pratique, ceci est indésirable, vous
voudrez probablement lister les colonnes explicitement plutôt
que d'utiliser <literal>*</literal> :
@@ -526,11 +527,11 @@
Maintenant, nous allons essayer de comprendre comment nous pouvons
avoir les entrées de Hayward. Nous voulons que la requête parcourt
- la table <classname>temps</classname> et que, pour chaque ligne,
- elle trouve la (ou les) ligne(s) de <classname>villes</classname>
+ la table <structname>temps</structname> et que, pour chaque ligne,
+ elle trouve la (ou les) ligne(s) de <structname>villes</structname>
correspondante(s). Si aucune ligne correspondante n'est trouvée,
nous voulons que les valeurs des colonnes de la table
- <classname>villes</classname> soient remplacées par des
+ <structname>villes</structname> soient remplacées par des
<quote>valeurs vides</quote>. Ce genre de requêtes est appelé
<firstterm>jointure externe</firstterm> (outer join). (Les
jointures que nous avons vus jusqu'ici sont des jointures internes
@@ -578,10 +579,10 @@
temps qui sont dans un intervalle de température d'autres entrées
de temps. Nous avons donc besoin de comparer les colonnes
<structfield>t_basse</structfield> et <structfield>t_haute</structfield> de chaque ligne
- de <classname>temps</classname> aux colonnes
+ de <structname>temps</structname> aux colonnes
<structfield>t_basse</structfield> et
<structfield>t_haute</structfield> de toutes les autres lignes de
- <classname>temps</classname>. Nous pouvons faire cela avec la
+ <structname>temps</structname>. Nous pouvons faire cela avec la
requête suivante :
<programlisting>SELECT T1.ville, T1.t_basse AS bas, T1.t_haute AS haut,
@@ -714,7 +715,7 @@
(1 row)</screen>
ce qui nous donne le même résultat uniquement pour les villes qui
- ont toutes leurs valeurs de <literal>t_basse</literal> en-dessous de 40.
+ ont toutes leurs valeurs de <structfield>t_basse</structfield> en-dessous de 40.
Pour finir, si nous nous préoccupons seulement des villes dont le
nom commence par <quote><literal>S</literal></quote>, nous pouvons
faire :
Modified: traduc/trunk/postgresql/ref/alter_foreign_data_wrapper.xml
===================================================================
--- traduc/trunk/postgresql/ref/alter_foreign_data_wrapper.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/ref/alter_foreign_data_wrapper.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -7,6 +7,7 @@
<refentry id="sql-alterforeigndatawrapper">
<refmeta>
<refentrytitle id="sql-alterforeigndatawrapper-title">ALTER FOREIGN DATA WRAPPER</refentrytitle>
+ <manvolnum>7</manvolnum>
<refmiscinfo>SQL - Instructions du langage</refmiscinfo>
</refmeta>
Modified: traduc/trunk/postgresql/ref/alter_server.xml
===================================================================
--- traduc/trunk/postgresql/ref/alter_server.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/ref/alter_server.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -7,6 +7,7 @@
<refentry id="sql-alterserver">
<refmeta>
<refentrytitle id="sql-alterserver-title">ALTER SERVER</refentrytitle>
+ <manvolnum>7</manvolnum>
<refmiscinfo>SQL - Instructions du langage</refmiscinfo>
</refmeta>
Modified: traduc/trunk/postgresql/ref/alter_user_mapping.xml
===================================================================
--- traduc/trunk/postgresql/ref/alter_user_mapping.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/ref/alter_user_mapping.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -7,6 +7,7 @@
<refentry id="sql-alterusermapping">
<refmeta>
<refentrytitle id="sql-alterusermapping-title">ALTER USER MAPPING</refentrytitle>
+ <manvolnum>7</manvolnum>
<refmiscinfo>SQL - Instructions du langage</refmiscinfo>
</refmeta>
Modified: traduc/trunk/postgresql/ref/create_foreign_data_wrapper.xml
===================================================================
--- traduc/trunk/postgresql/ref/create_foreign_data_wrapper.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/ref/create_foreign_data_wrapper.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -7,6 +7,7 @@
<refentry id="sql-createforeigndatawrapper">
<refmeta>
<refentrytitle id="sql-createforeigndatawrapper-title">CREATE FOREIGN DATA WRAPPER</refentrytitle>
+ <manvolnum>7</manvolnum>
<refmiscinfo>SQL - Instructions du langage</refmiscinfo>
</refmeta>
@@ -108,8 +109,10 @@
rudimentaire. Le but des wrappers de données distantes, des serveurs
distants et des correspondances d'utilisateurs est de stocker cette
information de manière standard, afin qu'elle puisse être interrogée par
- les applications intéressées. La fonctionnalité d'interroger réellement des
- données distantes n'existe pas encore.
+ les applications intéressées. Une application utilisant cette fonctionnalité
+ est <application>dblink</application> ; voir <xref linkend="dblink"/>.
+ La fonctionnalité permettant d'exécuter une requête sur des données distantes
+ via une bibliothèque de wrapper de données distantes n'existe pas encore.
</para>
<para>
Modified: traduc/trunk/postgresql/ref/create_server.xml
===================================================================
--- traduc/trunk/postgresql/ref/create_server.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/ref/create_server.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -7,6 +7,7 @@
<refentry id="sql-createserver">
<refmeta>
<refentrytitle id="sql-createserver-title">CREATE SERVER</refentrytitle>
+ <manvolnum>7</manvolnum>
<refmiscinfo>SQL - Instructions du langage</refmiscinfo>
</refmeta>
@@ -36,6 +37,14 @@
</para>
<para>
+ Un serveur distant englobe typiquement des informations de connexion qu'un
+ wrapper de données distantes utilise pour accéder à une ressource externe
+ de données. Des informations de connexions supplémentaires spécifiques à
+ l'utilisateur pourraient être fournies par l'intermédiaire des correspondances
+ d'utilisateur.
+ </para>
+
+ <para>
Le nom du serveur doit être unique dans la base de données.
</para>
@@ -99,6 +108,19 @@
</refsect1>
<refsect1>
+ <title>Notes</title>
+
+ <para>
+ Lors de l'utilisation du module <application>dblink</application>
+ (voir <xref linkend="dblink"/>), le nom du serveur distant peut être utilisé
+ comme argument de la fonction <xref linkend="contrib-dblink-connect"/> pour
+ indiquer les paramètres de connexion. Voir aussi ici pour plus d'exemples.
+ Il est nécessaire de disposer du droit <literal>USAGE</literal> sur le
+ serveur distant pour être capable de l'utiliser de cette façon.
+ </para>
+ </refsect1>
+
+ <refsect1>
<title>Exemples</title>
<para>
Modified: traduc/trunk/postgresql/ref/create_user_mapping.xml
===================================================================
--- traduc/trunk/postgresql/ref/create_user_mapping.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/ref/create_user_mapping.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -7,6 +7,7 @@
<refentry id="sql-createusermapping">
<refmeta>
<refentrytitle id="sql-createusermapping-title">CREATE USER MAPPING</refentrytitle>
+ <manvolnum>7</manvolnum>
<refmiscinfo>SQL - Instructions du langage</refmiscinfo>
</refmeta>
@@ -35,7 +36,9 @@
<para>
<command>CREATE USER MAPPING</command> définit une nouvelle correspondance
d'utilisateur (<foreignphrase>user mapping</foreignphrase>) pour un serveur
- distant.
+ distant. Une correspondance d'utilisateur englobe typiquement les informations
+ de connexion qu'un wrapper de données distantes utilise avec l'information
+ d'un serveur distant pour accéder à des ressources externes de données.
</para>
<para>
@@ -59,8 +62,9 @@
serveur distant.
<literal>CURRENT_USER</literal> et <literal>USER</literal> correspondent
au nom de l'utilisateur courant.
- <literal>PUBLIC</literal> est utilisé pour correspondre à tous les
- noms d'utilisateurs présents et futurs du système.
+ Quand <literal>PUBLIC</literal> est ajoutée, une correspondance appelée
+ publique est créée pour être utilisée quand aucune correspondance
+ d'utilisateur spécifique n'est applicable.
</para>
</listitem>
</varlistentry>
Modified: traduc/trunk/postgresql/ref/drop_foreign_data_wrapper.xml
===================================================================
--- traduc/trunk/postgresql/ref/drop_foreign_data_wrapper.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/ref/drop_foreign_data_wrapper.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -7,6 +7,7 @@
<refentry id="sql-dropforeigndatawrapper">
<refmeta>
<refentrytitle id="sql-dropforeigndatawrapper-title">DROP FOREIGN DATA WRAPPER</refentrytitle>
+ <manvolnum>7</manvolnum>
<refmiscinfo>SQL - Instructions du langage</refmiscinfo>
</refmeta>
Modified: traduc/trunk/postgresql/ref/drop_server.xml
===================================================================
--- traduc/trunk/postgresql/ref/drop_server.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/ref/drop_server.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -7,6 +7,7 @@
<refentry id="sql-dropserver">
<refmeta>
<refentrytitle id="sql-dropserver-title">DROP SERVER</refentrytitle>
+ <manvolnum>7</manvolnum>
<refmiscinfo>SQL - Instructions du langage</refmiscinfo>
</refmeta>
Modified: traduc/trunk/postgresql/ref/drop_user_mapping.xml
===================================================================
--- traduc/trunk/postgresql/ref/drop_user_mapping.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/ref/drop_user_mapping.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -7,6 +7,7 @@
<refentry id="sql-dropusermapping">
<refmeta>
<refentrytitle id="sql-dropusermapping-title">DROP USER MAPPING</refentrytitle>
+ <manvolnum>7</manvolnum>
<refmiscinfo>SQL - Instructions du langage</refmiscinfo>
</refmeta>
Modified: traduc/trunk/postgresql/ref/move.xml
===================================================================
--- traduc/trunk/postgresql/ref/move.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/ref/move.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -41,6 +41,8 @@
</para>
<para>
+ Les paramètres de la commande <command>MOVE</command> sont identiques à ceux
+ de la commande <command>FETCH</command>.
<xref linkend="sql-fetch" endterm="sql-fetch-title"/> contient les détails de
syntaxe et d'utilisation.
</para>
Modified: traduc/trunk/postgresql/release-8.4.xml
===================================================================
--- traduc/trunk/postgresql/release-8.4.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/release-8.4.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -35,7 +35,7 @@
<listitem>
<para>
- Common Table Expressions and Recursive Joins
+ Common Table Expressions and Recursive Queries
</para>
</listitem>
Modified: traduc/trunk/postgresql/rowtypes.xml
===================================================================
--- traduc/trunk/postgresql/rowtypes.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/rowtypes.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -230,7 +230,7 @@
éléments qui sont interprétés suivant les règles de conversion
d'entrées/sorties pour les types de champs individuels, plus des décorations
indiquant la structure composite. Cette décoration consiste en des parenthèses
- autour de la valeur entière ainsi que des
+ (<literal>(</literal> et <literal>)</literal>) autour de la valeur entière ainsi que des
virgules (<literal>,</literal>) entre les éléments adjacents. Des espace blancs en
dehors des parenthèses sont ignorés mais à l'intérieur des parenthèses, ils
sont considérés comme faisant partie de la valeur du champ et pourrait ou non
Modified: traduc/trunk/postgresql/start.xml
===================================================================
--- traduc/trunk/postgresql/start.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/start.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -172,7 +172,7 @@
<screen>createdb: command not found</screen>
alors <productname>PostgreSQL</productname> n'a pas été installé
correctement. Soit il n'a pas été installé du tout, soit le
- chemin système n'a pas été configuré correctement. Essayez d'appeler
+ chemin système n'a pas été configuré pour l'inclure. Essayez d'appeler
la commande avec le chemin absolu :
<screen><prompt>$</prompt> <userinput>/usr/local/pgsql/bin/createdb ma_base</userinput></screen>
Le chemin sur votre serveur peut être différent. Contactez votre
Modified: traduc/trunk/postgresql/storage.xml
===================================================================
--- traduc/trunk/postgresql/storage.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/storage.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -148,10 +148,10 @@
<xref linkend="storage-fsm"/>), qui stocke des informations sur les emplacements
libres dans la relation. La carte des espace libre est stockée dans un fichier
nommé par le numéro relfilenode à qui est ajouté le suffixe
-<literal>_fsm</literal>. Les tables ont aussi un fichier pour la carte de
-visibilité, de suffixe <literal>_vm</literal>, pour tracer les pages connues
-pour n'avoir aucune ligne morte (et du coup ne nécessitant pas d'opérations de
-VACUUM).
+<literal>_fsm</literal>. Les tables ont aussi un fichier pour la <firstterm>carte de
+visibilité</firstterm>, de suffixe <literal>_vm</literal>, pour tracer les pages connues
+pour n'avoir aucune ligne morte.
+La carte de visibilité est décrite plus bas dans <xref linkend="storage-vm"/>.
</para>
<caution>
@@ -457,6 +457,38 @@
</sect1>
+<sect1 id="storage-vm">
+
+<title>Visibility Map</title>
+
+<indexterm>
+ <primary>Visibility Map</primary>
+</indexterm>
+<indexterm><primary>VM</primary><see>Visibility Map</see></indexterm>
+
+<para>
+Each heap relation has a Visibility Map
+(VM) to keep track of which pages contain only tuples that are known to be
+visible to all active transactions. It's stored
+alongside the main relation data in a separate relation fork, named after the
+filenode number of the relation, plus a <literal>_vm</literal> suffix. For example,
+if the filenode of a relation is 12345, the VM is stored in a file called
+<filename>12345_vm</filename>, in the same directory as the main relation file.
+Note that indexes do not have VMs.
+</para>
+
+<para>
+The visibility map simply stores one bit per heap page. A set bit means
+that all tuples on the page are known to be visible to all transactions.
+This means that the page does not contain any tuples that need to be vacuumed;
+in future it might also be used to avoid visiting the page for visibility
+checks. The map is conservative in the sense that we
+make sure that whenever a bit is set, we know the condition is true, but if
+a bit is not set, it might or might not be true.
+</para>
+
+</sect1>
+
<sect1 id="storage-page-layout">
<title>Emplacement des pages de la base de données</title>
Modified: traduc/trunk/postgresql/syntax.xml
===================================================================
--- traduc/trunk/postgresql/syntax.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/syntax.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -434,7 +434,7 @@
</caution>
<para>
- Le caractère zéro (octet nul) ne peut être placé dans une constante de type
+ Le caractère de code zéro ne peut être placé dans une constante de type
chaîne.
</para>
</sect3>
@@ -916,8 +916,8 @@
</para>
<para>
- Les commentaires sont supprimés du flux en entrée avant une analyse plus
- poussée de la syntaxe et sont remplacés par un espace blanc.
+ Un commentaire est supprimé du flux en entrée avant une analyse plus
+ poussée de la syntaxe et est remplacé par un espace blanc.
</para>
</sect2>
Modified: traduc/trunk/postgresql/textsearch.xml
===================================================================
--- traduc/trunk/postgresql/textsearch.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/textsearch.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -916,7 +916,8 @@
</indexterm>
<synopsis>
- ts_rank(<optional> <replaceable class="parameter">weights</replaceable> <type>float4[]</type>, </optional> <replaceable class="parameter">vector</replaceable> <type>tsvector</type>, <replaceable class="parameter">query</replaceable> <type>tsquery</type> <optional>, <replaceable class="parameter">normalization</replaceable> <type>integer</type> </optional>) returns <type>float4</type>
+ ts_rank(<optional> <replaceable class="PARAMETER">weights</replaceable> <type>float4[]</type>, </optional> <replaceable class="PARAMETER">vector</replaceable> <type>tsvector</type>,
+ <replaceable class="PARAMETER">query</replaceable> <type>tsquery</type> <optional>, <replaceable class="PARAMETER">normalization</replaceable> <type>integer</type> </optional>) returns <type>float4</type>
</synopsis>
</term>
@@ -1806,7 +1807,9 @@
</para>
<synopsis>
- ts_stat(<replaceable class="parameter">sqlquery</replaceable> <type>text</type>, <optional> <replaceable class="parameter">weights</replaceable> <type>text</type>, </optional> OUT <replaceable class="parameter">word</replaceable> <type>text</type>, OUT <replaceable class="parameter">ndoc</replaceable> <type>integer</type>, OUT <replaceable class="parameter">nentry</replaceable> <type>integer</type>) returns <type>setof record</type>
+ ts_stat(<replaceable class="parameter">sqlquery</replaceable> <type>text</type>, <optional> <replaceable class="parameter">weights</replaceable> <type>text</type>, </optional>
+ OUT <replaceable class="parameter">word</replaceable> <type>text</type>, OUT <replaceable class="parameter">ndoc</replaceable> <type>integer</type>,
+ OUT <replaceable class="parameter">nentry</replaceable> <type>integer</type>) returns <type>setof record</type>
</synopsis>
<para>
Modified: traduc/trunk/postgresql/typeconv.xml
===================================================================
--- traduc/trunk/postgresql/typeconv.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/typeconv.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -181,8 +181,8 @@
(Pour une liste, voir <xref linkend="catalog-typcategory-table"/> ; mais
notez qu'il est aussi possible de créer des catégories de type personnalisées.)
À l'intérieur de chaque catégorie, il peut y avoir une ou plusieurs
-<firstterm>types préférés</firstterm>, qui sont sélectionnés par préférence
-quand il n'y a plus d'ambiguïtés. Avec une sélection attentive des types
+<firstterm>types préférés</firstterm>, qui sont sélectionnés quand il y a un
+choix possible de types. Avec une sélection attentive des types
préférés et des conversions implicites disponibles, il est possible de s'assurer
que les expressions ambigues (celles avec plusieurs solutions candidates) peuvent
être résolus d'une façon utile.
@@ -232,10 +232,11 @@
</indexterm>
<para>
- L'opérateur spécifique employé est déterminé par la procédure ci-dessous.
- Notez que cette procédure est indirectement affectée par l'ordre d'insertion
- des opérateurs. Voir la <xref linkend="sql-precedence"/> pour plus de
- détails.
+ L'opérateur spécifique qui est référence par une expression d'opérateur
+ est déterminé par la procédure ci-dessous. Notez que cette procédure est
+ indirectement affectée par l'ordre d'insertion des opérateurs car cela va
+ déterminer les sous-expressions prises en entrée des opérateurs. Voir la
+ <xref linkend="sql-precedence"/> pour plus d'informations.
</para>
<procedure>
@@ -279,9 +280,10 @@
<para>
Si un argument lors d'une invocation d'opérateur binaire est de type
<type>unknown</type> (NdT : inconnu), alors considérer pour ce contrôle
-que c'est le même type que l'autre argument. Les cas impliquant deux types
-<type>unknown</type> ne trouveront jamais une correspondance à ce
-niveau.
+que c'est le même type que l'autre argument. Les invocations impliquant deux
+entrées de type <type>unknown</type>, ou un opérateur unitaire avec en entrée
+une donnée de type <type>unknown</type> ne trouveront jamais une correspondance
+à ce niveau.
</para>
</step>
</substeps>
@@ -486,7 +488,7 @@
</indexterm>
<para>
- La fonction spécifique à utiliser dans un appel de fonction
+ La fonction spécifique référencée par un appel de fonction
est déterminée selon les étapes suivantes.
</para>
@@ -651,8 +653,8 @@
<para>
Il n'existe qu'une seule fonction <function>round</function>
-avec deux arguments (le premier est un <type>numeric</type>, le
-second est un <type>integer</type>). Ainsi, la requête suivante
+avec deux arguments (le premier est de type <type>numeric</type>, le
+second est de type <type>integer</type>). Ainsi, la requête suivante
convertie automatiquement le type du premier argument de
<type>integer</type> vers <type>numeric</type>.
Modified: traduc/trunk/postgresql/version.xml
===================================================================
--- traduc/trunk/postgresql/version.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/version.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -1,2 +1,2 @@
-<!ENTITY version "8.4RC1">
+<!ENTITY version "8.4RC2">
<!ENTITY majorversion "8.4">
Modified: traduc/trunk/postgresql/xaggr.xml
===================================================================
--- traduc/trunk/postgresql/xaggr.xml 2009-06-23 16:25:46 UTC (rev 1351)
+++ traduc/trunk/postgresql/xaggr.xml 2009-06-23 22:14:31 UTC (rev 1352)
@@ -164,11 +164,15 @@
(IsA(fcinfo->context, AggState) ||
IsA(fcinfo->context, WindowAggState)))
</programlisting>
- L'intérêt de cette vérification est que, lorsque cela est vrai, la première
+ L'intérêt de cette vérification est que, lorsque cela est vrai pour une
+ fonction de transition, la première
entrée doit être une valeur de transition, temporaire, et peut donc être
modifiée sans risque plutôt que d'allouer une nouvelle copie (ceci est
<emphasis>seulement</emphasis> le cas quand la modification d'une entrée passée par
- référence est sûre pour une fonction). Voir <literal>int8inc()</literal> pour un
+ référence est sûre pour une fonction. En particulier, les fonctions finales
+ d'agrégat ne devraient pas modifier leurs entrées dans tous les cas car
+ elles seront ré-exécutées dans certains cas sur la même valeur de transition
+ finale). Voir <literal>int8inc()</literal> pour un
exemple.
</para>
<!-- Rien compris -->
Plus d'informations sur la liste de diffusion Trad