Vous n'avez pas besoin d'échapper - à l'intérieur des classes de caractères lorsque vous le placez en première ou en dernière position, car il ne peut pas être mal interprété comme une plage de cette façon :
[\- ] -> [- ] [\d\- ] -> [\d -]
La façon dont vous l'avez la limite supérieure 10 à la fin est futile.
Ajouter $ à la fin pour interdire les caractères de fin.
Ou \D pour interdire les chiffres de fin (mais nécessite un non-chiffre).
Ou ($|\D) pour terminer la chaîne ici ou avoir un suivi non numérique.
Réunissez :
SELECT '+79637434199' ~ '^(8|\+7)[ -]?(\(?\d{3}\)?[ -]?)[\d -]{7,10}($|\D)'
Sinon, votre expression est très bien et cela fonctionne pour moi sur PostgreSQL 9.1.4. Cela ne devrait faire aucune différence que vous l'utilisiez dans un WHERE clause ou dans un SELECT list - sauf si vous rencontrez un bogue avec une ancienne version (comme @kgrittn suggéré dans les commentaires).
Si je préfixe la chaîne littérale avec E , je peux provoquer le message d'erreur que vous obtenez. Cela ne peut pas expliquez votre problème, car vous avez déclaré que l'expression fonctionne bien comme SELECT élément.
Mais, comme Sherlock Holmes est cité, "lorsque vous avez exclu l'impossible, tout ce qui reste, aussi improbable soit-il, doit être la vérité."
Peut-être avez-vous effectué un test avec standard_conforming_strings = on
et l'autre avec standard_conforming_strings = off - c'était l'interprétation par défaut des littéraux de chaîne dans les anciennes versions avant 9.1. Peut-être avec deux clients différents (qui ont un paramètre différent à ce sujet).
Lire la suite dans le chapitre String Constants avec des évasions de style C dans le manuel.
