Il crée un implicite CROSS JOIN
. C'est la syntaxe SQL-89.
Ici, j'utilise values(1)
et values(2)
pour créer des pseduo-tables (tables de valeurs) uniquement à titre d'exemples. La chose après eux t(x)
, et g(y)
sont appelés FROM-Alias, le caractère à l'intérieur de la parenthèse est l'alias de la colonne ( x
et y
respectivement). Vous pouvez tout aussi facilement créer un tableau pour tester cela.
SELECT *
FROM (values(1)) AS t(x), (values(2)) AS g(y)
Voici comment vous l'écririez maintenant.
SELECT *
FROM (values(1)) AS t(x)
CROSS JOIN (values(2)) AS g(y);
De là, vous pouvez en faire un implicite INNER JOIN
en ajoutant un conditionnel.
SELECT *
FROM (values(1)) AS t(x)
CROSS JOIN (values(1)) AS g(z)
WHERE x = z;
Ou la INNER JOIN
syntaxe explicite et plus récente ,
SELECT *
FROM (values(1)) AS t(x)
INNER JOIN (values(1)) AS g(z)
ON ( x = z );
Donc, dans votre exemple ..
FROM apod, to_tsquery('neutrino|(dark & matter)') query
C'est essentiellement la même que la nouvelle syntaxe,
FROM apod
CROSS JOIN to_tsquery('neutrino|(dark & matter)') AS query
qui est en fait le même, dans ce cas, car to_tsquery()
renvoie une ligne et non un ensemble comme,
SELECT title, ts_rank_cd(
textsearch,
to_tsquery('neutrino|(dark & matter)')
) AS rank
FROM apod
WHERE to_tsquery('neutrino|(dark & matter)') @@ textsearch
ORDER BY rank DESC
LIMIT 10;
Cependant, ce qui précède pourrait potentiellement to_tsquery('neutrino|(dark & matter)')
se produire deux fois, mais dans ce cas, il ne l'est pas - to_tsquery
est marqué comme STABLE (vérifié avec \dfS+ to_tsquery
).
STABLE
indique que la fonction ne peut pas modifier la base de données et qu'au sein d'une analyse de table unique, elle retournera systématiquement le même résultat pour les mêmes valeurs d'argument, mais que son résultat pourrait changer d'une instruction SQL à l'autre. Il s'agit de la sélection appropriée pour les fonctions dont les résultats dépendent des recherches dans la base de données, des variables de paramètres (comme le fuseau horaire actuel), etc. La famille de fonctions current_timestamp est considérée comme stable, car leurs valeurs ne changent pas dans une transaction.
Pour une comparaison plus complète des différences entre SQL-89 et SQL-92, voir également ma réponse ici
,
soit une jointure croisée car il ne s'agit que d'un produit cartésien et aucune comparaison n'est impliquée. Pouvez-vous simplement répondre à 1 autre question S'IL VOUS PLAÎT? ce qui estt(x)
en(values(1)) AS t(x)
???