Skip to content

Commit

Permalink
Update xfunc.xml
Browse files Browse the repository at this point in the history 
fin de traduction du fichier
  • Loading branch information
@julien2512
julien2512 committed Jun 21, 2013
1 parent f5220a5 commit f7f33fb
Showing 1 changed file with 58 additions and 58 deletions.
116 changes: 58 additions & 58 deletions postgresql/xfunc.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -903,13 +903,13 @@ SELECT * FROM sum_n_product_with_tab(10);
</para>

<para>
It is frequently useful to construct a query's result by invoking a
set-returning function multiple times, with the parameters for each
invocation coming from successive rows of a table or subquery. The
preferred way to do this is to use the <literal>LATERAL</literal> key word,
which is described in <xref linkend="queries-lateral"/>.
Here is an example using a set-returning function to enumerate
elements of a tree structure:
Il est souvent utile de construire le résultat d'une requête par l'appel répété
d'une fonction retournant un ensemble, dont les paramètres de chaque appel varient
avec les valeurs des lignes d'une table ou d'une sous-requête. La manière idéale
de le réaliser est d'utiliser le mot clé <literal>LATERAL</literal>,
qui est décrit dans <xref linkend="queries-lateral"/>.
Voici un exemple de fonction retournant un ensemble permettant d'énumérer
les éléments d'une structure en arbre :

<screen>SELECT * FROM noeuds;
nom | parent
Expand All @@ -922,42 +922,42 @@ SELECT * FROM sum_n_product_with_tab(10);
Sous-Enfant2 | Enfant1
(6 rows)

CREATE FUNCTION listchildren(text) RETURNS SETOF text AS $$
SELECT name FROM nodes WHERE parent = $1
CREATE FUNCTION listeenfant(text) RETURNS SETOF text AS $$
SELECT nom FROM noeuds WHERE parent = $1
$$ LANGUAGE SQL STABLE;

SELECT * FROM listchildren('Top');
listchildren
SELECT * FROM listeenfant('Haut');
listeenfant
--------------
Child1
Child2
Child3
Enfant1
Enfant2
Enfant3
(3 rows)

SELECT name, child FROM nodes, LATERAL listchildren(name) AS child;
name | child
--------+-----------
Top | Child1
Top | Child2
Top | Child3
Child1 | SubChild1
Child1 | SubChild2
SELECT nom, enfant FROM noeuds, LATERAL listeenfant(nom) AS enfant;
name | child
---------+-------------
Haut | Enfant1
Haut | Enfant2
Haut | Enfant3
Enfant1 | Sous-Enfant1
Enfant1 | Sous-Enfant2
(5 rows)
</screen>

This example does not do anything that we couldn't have done with a
simple join, but in more complex calculations the option to put
some of the work into a function can be quite convenient.
Cet exemple ne fait rien de plus que ce qui aurait été possible avec
une simple jointure, mais dans des cas plus compliqués l'alternative
consistant à reporter du travail dans une fonction peut se révéler assez pratique.
</para>

<para>
Currently, functions returning sets can also be called in the select list
of a query. For each row that the query
generates by itself, the function returning set is invoked, and an output
row is generated for each element of the function's result set. Note,
however, that this capability is deprecated and might be removed in future
releases. The previous example could also be done with queries like
these:
Actuellement, les fonctions retournant des ensembles peuvent aussi être appelées
dans la clause select d'une requête. Pour chaque ligne que cette requête génére
par elle-même, la fonction retournant un ensemble est invoquée, et une ligne-résultat
est générée pour chaque élément de l'ensemble retourné par la fonction. A noter
cependant que cette fonctionnalité est dépréciée et devrait être supprimée dans
les prochaines versions. L'exemple précédent peut aussi être implémenté avec des
requêtes telles que:

<screen>

Expand All @@ -983,9 +983,9 @@ SELECT nom, listeenfant(nom) FROM noeuds;
Notez, dans le dernier <command>SELECT</command>, qu'aucune ligne n'est
renvoyée pour <literal>Enfant2</literal>, <literal>Enfant3</literal>, etc. C'est parce
que la fonction <function>listeenfant</function> renvoie un ensemble vide
pour ces arguments et ainsi aucune ligne n'est générée. This is the same
behavior as we got from an inner join to the function result when using
the <literal>LATERAL</literal> syntax.
pour ces arguments et ainsi aucune ligne n'est générée. Ce comportement
est le même que celui attendu par une requête inner join avec le résultat
de la fonction en utilisant la syntaxe <literal>LATERAL</literal>.
</para>

<note>
Expand All @@ -1004,14 +1004,14 @@ SELECT nom, listeenfant(nom) FROM noeuds;

<note>
<para>
The key problem with using set-returning functions in the select list,
rather than the <literal>FROM</literal> clause, is that putting more than one
set-returning function in the same select list does not behave very
sensibly. (What you actually get if you do so is a number of output
rows equal to the least common multiple of the numbers of rows produced
by each set-returning function.) The <literal>LATERAL</literal> syntax
produces less surprising results when calling multiple set-returning
functions, and should usually be used instead.
Le principal problème lorsque l'on utiliser une fonction retournant une liste
dans la clause <literal>SELECT</literal> plutôt que dans la clause <literal>FROM</literal>,
est que l'ajout de plus d'une fonction retournant un ensemble dans la même clause <literal>SELECT</literal>
ne se comporte pas correctement (ce que nous obtenons actuellement est une liste
dont la taille est le plus petit commun multiple du nombre de ligne produites
par chaque fonction retournant un ensemble.) La syntaxe <literal>LATERAL</literal>
génére un résulant moins surprenant avec de multiples fonctions retournant des ensembles,
et devrait préférentiellement être utilisée.
</para>
</note>
</sect2>
Expand Down Expand Up @@ -1809,11 +1809,11 @@ PG_MODULE_MAGIC;
typedef int int4;
</programlisting>

(The actual PostgreSQL C code calls this type <type>int32</type>, because
it is a convention in C that <type>int<replaceable>XX</replaceable></type>
means <replaceable>XX</replaceable> <emphasis>bits</emphasis>. Note
therefore also that the C type <type>int8</type> is 1 byte in size. The
SQL type <type>int8</type> is called <type>int64</type> in C. See also
(le vrai code C de PostgreSQL appelle ce type <type>int32</type> car il
existe une convention en C disant que <type>int<replaceable>XX</replaceable></type>
signifie <replaceable>XX</replaceable> <emphasis>bits</emphasis>. A noter aussi
toutefois que le type C <type>int8</type> a une taille d'un byte. Le type SQL
<type>int8</type> est appelé <type>int64</type> en C. Voir aussi
<xref linkend="xfunc-c-type-table"/>.)

</para>
Expand Down Expand Up @@ -3166,10 +3166,10 @@ CREATE OR REPLACE FUNCTION retcomposite(integer, integer)
<literal>fcinfo-&gt;flinfo</literal>. Le paramètre <literal>argnum</literal> est basé à
partir de zéro. <function>get_call_result_type</function> peut aussi être utilisé
comme alternative à <function>get_fn_expr_rettype</function>.
There is also <function>get_fn_expr_variadic</function>, which can be used to
find out whether the call contained an explicit <literal>VARIADIC</literal>
keyword. This is primarily useful for <literal>VARIADIC "any"</literal>
functions, as described below.
Il existe aussi une fonction <function>get_fn_expr_variadic</function>, qui peut être utilisée pour
savoir si l'appel contient explicitement un mot clé <literal>VARIADIC</literal>.
Cela peut être réellement utile pour les fonctions <literal>VARIADIC "any"</literal>,
comme décrit plus bas.
</para>

<para>
Expand Down Expand Up @@ -3252,12 +3252,12 @@ make_array(PG_FUNCTION_ARGS)
passés séparément à la fonction. La macro <function>PG_NARGS()</function>
et les méthodes décrites ci-dessus doivent être utilisées pour déterminer
le nombre d'arguments réels et leur type lors de l'utilisation de cette
fonctionnalité. Also, users of such
a function might wish to use the <literal>VARIADIC</literal> keyword in their
function call, with the expectation that the function would treat the
array elements as separate arguments. The function itself must implement
that behavior if wanted, after using <function>get_fn_expr_variadic</function> to
detect that the actual argument was marked with <literal>VARIADIC</literal>.
fonctionnalité. Ainsi, les utilisateurs d'une telle fonction voudront
probablement utilisé le mot-clé <literal>VARIADIC</literal> dans leur
appel de fonction, de manière à ce que la fonction traite les éléments
du tableau comme des arguments séparés. La fonction elle-même doit implémenter
ce comportement si nécessaire, après avoir utilisé <function>get_fn_expr_variadic</function> pour
savoir si les arguments actuels ont été marqué avec <literal>VARIADIC</literal>.
</para>
</sect2>

Expand Down

0 comments on commit f7f33fb

Please sign in to comment.