Vous ne pouvez pas compter sur l'ordre des lignes dans une requête qui n'a pas de ORDER BY explicite clause. Si vous interrogez une vue ordonnée, mais que vous n'incluez pas de ORDER BY clause, soyez agréablement surpris s'ils sont dans le bon ordre et ne vous attendez pas à ce que cela se reproduise.
En effet, l'optimiseur de requête est libre d'accéder aux lignes de différentes manières en fonction de la requête, des statistiques de la table, du nombre de lignes, des index, etc. S'il sait que votre requête n'a pas de ORDER BY clause, il est libre d'ignorer l'ordre des lignes dans l'ordre (tousse) pour retourner les lignes plus rapidement.
Légèrement hors sujet . . .
L'ordre de tri n'est pas nécessairement identique sur toutes les plates-formes, même pour les classements bien connus. Je comprends que le tri UTF-8 sur Mac OS X est particulièrement étrange. (Les développeurs PostgreSQL l'appellent cassé .) PostgreSQL s'appuie sur strcoll(), qui, je comprends, repose sur les paramètres régionaux du système d'exploitation.
Je ne sais pas comment PostgreSQL 9.1 gérera cela. Dans 9.1, vous pouvez avoir plusieurs index, chacun avec un classement différent . Un ORDER BY qui ne spécifie pas de classement utilisera généralement le classement des colonnes de la table de base sous-jacente, mais que fera l'optimiseur avec un index qui spécifie un classement différent d'une colonne non indexée dans la table de base ?
