Skip to content

Commit

Permalink
Les deux derniers fichiers
Browse files Browse the repository at this point in the history
  • Loading branch information
@gleu
gleu committed Jul 23, 2017
1 parent 7fb7051 commit 4da6218
Show file tree
Hide file tree
Showing 2 changed files with 90 additions and 88 deletions.
102 changes: 53 additions & 49 deletions postgresql/xfunc.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -988,76 +988,80 @@ SELECT nom, listeenfant(nom) FROM noeuds;
</para>

<para>
<productname>PostgreSQL</productname>'s behavior for a set-returning function in a
query's select list is almost exactly the same as if the set-returning
function had been written in a <literal>LATERAL FROM</literal>-clause item
instead. For example,
Le comportement de <productname>PostgreSQL</productname> pour une
fonction renvoyant des lignes (SETOF) dans la liste SELECT d'une requête
est pratiquement identique à celui d'une fonction SETOF écrite dans une
clause <literal>LATERAL FROM</literal>. Par exemple&nbsp;:
<programlisting>
SELECT x, generate_series(1,5) AS g FROM tab;
</programlisting>
is almost equivalent to
est pratiquement équivalente à&nbsp;:
<programlisting>
SELECT x, g FROM tab, LATERAL generate_series(1,5) AS g;
</programlisting>
It would be exactly the same, except that in this specific example,
the planner could choose to put <structname>g</structname> on the outside of the
nestloop join, since <structname>g</structname> has no actual lateral dependency
on <structname>tab</structname>. That would result in a different output row
order. Set-returning functions in the select list are always evaluated
as though they are on the inside of a nestloop join with the rest of
the <literal>FROM</literal> clause, so that the function(s) are run to
completion before the next row from the <literal>FROM</literal> clause is
considered.
Ce serait exactement la même chose, sauf que dans cet exemple spécifique,
le planificateur pourrait choisir de placer <structname>g</structname> à
l'extérieur de la jointure de boucle imbriquée puisque
<structname>g</structname> n'a pas de réelle dépendance latérale sur
<structname>tab</structname>. Cela résulterait en un ordre différent des
lignes en sortie. Les fonctions SETOF dans la liste SELECT sont toujours
évaluées comme si elles étaient à l'intérieur d'une jointure de boucle
imbriquée avec le reste de la clause <literal>FROM</literal>, pour que
les fonctions soient exécutées complètement avant de considérer la
prochaine ligne provenant de la clause <literal>FROM</literal>.
</para>

<para>
If there is more than one set-returning function in the query's select
list, the behavior is similar to what you get from putting the functions
into a single <literal>LATERAL ROWS FROM( ... )</literal> <literal>FROM</literal>-clause
item. For each row from the underlying query, there is an output row
using the first result from each function, then an output row using the
second result, and so on. If some of the set-returning functions
produce fewer outputs than others, null values are substituted for the
missing data, so that the total number of rows emitted for one
underlying row is the same as for the set-returning function that
produced the most outputs. Thus the set-returning functions
run <quote>in lockstep</quote> until they are all exhausted, and then
execution continues with the next underlying row.
S'il y a plus d'une fonction SETOF dans la liste du SELECT de la requête,
le comportement est similaire à ce que vous obtiendriez en plaçant les
fonctions dans une seule clause <literal>FROM</literal> de
<literal>LATERAL ROWS FROM( ... )</literal>. Pour chaque ligne de la
requête sous-jacente, il existe une ligne en sortie utilisant le premier
résultat de chaque fonction, ensuite une ligne en sortie utilisant le
deuxième résultat, et ainsi de suite. Si certaines des fonctions SETOF
produisent moins de résultats que les autres, des valeurs NULL sont
ajoutées pour les données manquantes, pour que le nombre total de lignes
émises pour une ligne sous-jacente soit la même que pour la fonction
SETOF qui a produit le plus de lignes. De ce fait, les fonctions SETOF
s'exécutent complètement jusqu'à ce qu'elles aient terminé, puis
l'exécution continue avec la prochaine ligne sous-jacente.
</para>

<para>
Set-returning functions can be nested in a select list, although that is
not allowed in <literal>FROM</literal>-clause items. In such cases, each level
of nesting is treated separately, as though it were
a separate <literal>LATERAL ROWS FROM( ... )</literal> item. For example, in
Les fonctions SETOF peuvent être imbriquées dans une liste SELECT, bien
que cela ne soit pas autorisées dans les éléments d'une clause
<literal>FROM</literal>. Dans de tels cas, chaque niveau d'imbrication
est traité séparément, comme s'il s'agissait d'un élément
<literal>LATERAL ROWS FROM( ... )</literal> séparé. Par exemple, dans
<programlisting>
SELECT srf1(srf2(x), srf3(y)), srf4(srf5(z)) FROM tab;
</programlisting>
the set-returning functions <function>srf2</function>, <function>srf3</function>,
and <function>srf5</function> would be run in lockstep for each row
of <structname>tab</structname>, and then <function>srf1</function> and <function>srf4</function>
would be applied in lockstep to each row produced by the lower
functions.
les fonctions SETOF <function>srf2</function>, <function>srf3</function>,
et <function>srf5</function> seront exécutées ligne par ligne pour chaque
ligne de <structname>tab</structname>, puis <function>srf1</function> et
<function>srf4</function> seront appliquées ligne par ligne pour chaque
ligne produite par les fonctions inférieures.
</para>

<para>
Set-returning functions cannot be used within conditional-evaluation
constructs, such as <literal>CASE</literal> or <literal>COALESCE</literal>. For
example, consider
This behavior also means that set-returning functions will be evaluated
even when it might appear that they should be skipped because of a
conditional-evaluation construct, such as <literal>CASE</literal>
or <literal>COALESCE</literal>. For example, consider
Les fonctions SETOF ne peuvent pas être utilisées à l'intérieur de
constructions d'évaluations conditionnelles, telles que
<literal>CASE</literal> ou <literal>COALESCE</literal>. Ce comportement
signifie aussi que des fonctions SETOF seront évaluées même quand il
pourrait apparaître qu'elles devraient être ignorées grâce à une
construction d'évaluation conditionnelle, telle que
<literal>CASE</literal> ou <literal>COALESCE</literal>. Par exemple,
considérez&nbsp;:
<programlisting>
SELECT x, CASE WHEN x &gt; 0 THEN generate_series(1, 5) ELSE 0 END FROM tab;
</programlisting>
It might seem that this should produce five repetitions of input rows
that have <literal>x &gt; 0</literal>, and a single repetition of those that do
not; but actually, because <function>generate_series(1, 5)</function> would be
run in an implicit <literal>LATERAL FROM</literal> item before
the <literal>CASE</literal> expression is ever evaluated, it would produce five
repetitions of every input row. To reduce confusion, such cases produce
a parse-time error instead.
Il pourrait sembler que cela produit cinq répétitions des lignes en
entrée qui ont <literal>x &gt; 0</literal>, et une seule répétition des
autres parce que <function>generate_series(1, 5)</function> serait
exécuté dans un élément <literal>LATERAL FROM</literal> implicite,
l'expression <literal>CASE</literal> est toujours évaluée, elle
produirait cinq répétitions de chaque ligne en entrée. Pour diminuer la
confusion, ce genre de cas renvoie une erreur au moment de l'analyse.
</para>

<note>
Expand Down
76 changes: 37 additions & 39 deletions postgresql/xindex.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1184,58 +1184,56 @@ ALTER OPERATOR FAMILY integer_ops USING btree ADD
</sect2>

<sect2 id="xindex-ordering-ops">
<title>Ordering Operators</title>
<title>Opérateurs de tri</title>

<para>
Some index access methods (currently, only GiST) support the concept of
<firstterm>ordering operators</firstterm>. What we have been discussing so far
are <firstterm>search operators</firstterm>. A search operator is one for which
the index can be searched to find all rows satisfying
<literal>WHERE</literal>
<replaceable>indexed_column</replaceable>
<replaceable>operator</replaceable>
<replaceable>constant</replaceable>.
Note that nothing is promised about the order in which the matching rows
will be returned. In contrast, an ordering operator does not restrict the
set of rows that can be returned, but instead determines their order.
An ordering operator is one for which the index can be scanned to return
rows in the order represented by
<literal>ORDER BY</literal>
<replaceable>indexed_column</replaceable>
<replaceable>operator</replaceable>
<replaceable>constant</replaceable>.
The reason for defining ordering operators that way is that it supports
nearest-neighbor searches, if the operator is one that measures distance.
For example, a query like
Certaines méthodes d'accès aux index (actuellement seulement GiST)
supportent le concept d'<firstterm>opérateurs de tri</firstterm>. Nous
avons discuté jusqu'à maintenant d'<firstterm>opérateurs de
recherche</firstterm>. Un opérateur de recherche est utilisable pour
rechercher dans un index toutes les lignes satisfaisant le prédicat
<literal>WHERE</literal> <replaceable>colonne_indexée</replaceable>
<replaceable>operateur</replaceable> <replaceable>constante</replaceable>.
Notez que rien n'est promis sur l'ordre dans lequel les lignes
correspondantes seront renvoyées. Au contraire, un opérateur de tri ne
restreint pas l'ensemble de lignes qu'il peut renvoyer mais, à la place,
détermine leur ordre. Un opérateur de tri est utilisé pour que l'index
puisse être parcouru pour renvoyer les lignes dans l'ordre représenté par
<literal>ORDER BY</literal> <replaceable>colonne_indexée</replaceable>
<replaceable>opérateur</replaceable> <replaceable>constante</replaceable>.
Le but de définir des opérateurs de tri de cette façon est de supporter les
recherches du type plus-proche-voisin si l'opérateur sait mesurer les
distances. Par exemple, une requête comme
<programlisting><![CDATA[
SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10;
]]>
</programlisting>
finds the ten places closest to a given target point. A GiST index
on the location column can do this efficiently because
<literal>&lt;-&gt;</literal> is an ordering operator.
trouve les dix emplacements les plus proches d'un point cible donné. Un
index GiST sur la colonne location peut faire cela de façon efficace
parce que <literal>&lt;-&gt;</literal> est un opérateur de tri.
</para>

<para>
While search operators have to return Boolean results, ordering operators
usually return some other type, such as float or numeric for distances.
This type is normally not the same as the data type being indexed.
To avoid hard-wiring assumptions about the behavior of different data
types, the definition of an ordering operator is required to name
a B-tree operator family that specifies the sort ordering of the result
data type. As was stated in the previous section, B-tree operator families
define <productname>PostgreSQL</productname>'s notion of ordering, so
this is a natural representation. Since the point <literal>&lt;-&gt;</literal>
operator returns <type>float8</type>, it could be specified in an operator
class creation command like this:
Bien que les opérateurs de recherche doivent renvoyer des résultats
booléens, les opérateurs de tri renvoient habituellement d'autres types,
tel que des float ou numeric pour les distances. Ce type n'est
habituellement pas le même que le type de données indexé. Pour éviter les
suppositions en dur sur le comportement des différents types de données, la
définition d'un opérateur de tro doit nommer une famille d'opérateur B-tree
qui spécifie l'ordre de tri du type de données résultant. Comme indiqué
dans la section précédente, les familles d'opérateur B-tree définissent la
notion de tri de <productname>PostgreSQL</productname>, donc c'est une
représentation naturelle. Comme l'opérateur <literal>&lt;-&gt;</literal>
renvoie <type>float8</type>, il peut être indiqué dans la commande de
création d'une classe d'opérateur&nbsp;:
<programlisting><![CDATA[
OPERATOR 15 <-> (point, point) FOR ORDER BY float_ops
]]>
</programlisting>
where <literal>float_ops</literal> is the built-in operator family that includes
operations on <type>float8</type>. This declaration states that the index
is able to return rows in order of increasing values of the
<literal>&lt;-&gt;</literal> operator.
où <literal>float_ops</literal> est la famille d'opérateur interne qui
inclut les opérations sur <type>float8</type>. Cette déclaration indique
que l'index est capable de renvoyer des lignes dans l'ordre de valeurs de
plus en plus hautes de l'opérateur <literal>&lt;-&gt;</literal>.
</para>
</sect2>

Expand Down

0 comments on commit 4da6218

Please sign in to comment.