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)
???to_tsquery()
renvoie une valeur et non une ligne . Et juste parce qu'une fonction est définieSTABLE
, cela ne signifie pas le planificateur de requêtes va éviter l' évaluation répétée. C'est possible .Le manuel contient des explications détaillées sur la virgule dans la
FROM
liste du chapitre Expressions de table :Le fait que les références de table séparées par des virgules aient été définies dans une version antérieure du standard SQL que la
JOIN
syntaxe explicite ne rend pas la virgule incorrecte ou obsolète. Utilisez la syntaxe de jointure explicite, là où c'est techniquement nécessaire (voir ci-dessous) ou là où le texte de la requête est plus clair.Le manuel à nouveau:
Mais "équivalent" ne signifie pas identique . Il y a une différence subtile, comme le note le manuel :
Cette question connexe démontre la pertinence de la différence:
Fondamentalement, votre observation est exacte:
N'importe quelle fonction peut être utilisée comme "fonction de table" dans la
FROM
liste. Et les paramètres de fonction peuvent référencer des colonnes de toutes les tables à gauche de la fonction, car la notation:est vraiment équivalent à:
Le manuel sur les requêtes LATÉRALES:
Accentuation sur moi.
Le mot clé
AS
est un bruit complètement facultatif avant les alias de table (par opposition aux alias de colonne , où il est recommandé de ne pas les omettreAS
pour éviter d'éventuelles ambiguïtés). Réponse connexe avec plus:la source