Nie musisz uciekać - wewnątrz klas znaków, gdy umieścisz go na pierwszej lub ostatniej pozycji, ponieważ nie może być w ten sposób błędnie odczytany jako zakres:
[\- ] -> [- ] [\d\- ] -> [\d -]
Sposób, w jaki masz to górna granica 10 na końcu jest daremne.
Dodaj $ na końcu, aby nie zezwalać na znaki końcowe.
Lub \D aby zabronić końcowych cyfr (ale wymagają cyfry innej niż).
Lub ($|\D) aby albo zakończyć tam łańcuch, albo mieć następującą liczbę niecyfrową.
Razem:
SELECT '+79637434199' ~ '^(8|\+7)[ -]?(\(?\d{3}\)?[ -]?)[\d -]{7,10}($|\D)'
W przeciwnym razie twoje wyrażenie jest w porządku i działa dla mnie na PostgreSQL 9.1.4. Nie powinno mieć żadnej różnicy, czy użyjesz go w WHERE klauzula lub w SELECT lista - chyba że napotkasz błąd w jakiejś starej wersji (jak @kgrittn sugerowany w komentarzach).
Jeśli dołączę literał ciągu znaków z E , mogę sprowokować wyświetlany komunikat o błędzie. To nie może wyjaśnij swój problem, ponieważ stwierdziłeś, że wyrażenie działa dobrze jako SELECT element.
Ale, jak cytuje Sherlocka Holmesa, „kiedy wykluczyłeś niemożliwe, cokolwiek pozostaje, jakkolwiek nieprawdopodobne, musi być prawdą”.
Może wykonałeś jeden test z standard_conforming_strings = on
a drugi z standard_conforming_strings = off - była to domyślna interpretacja literałów ciągów znaków w starszych wersjach przed wersją 9.1. Może z dwoma różnymi klientami (którzy mają różne ustawienia).
Przeczytaj więcej w rozdziale Stałe łańcuchowe z Ucieczkami w stylu C w instrukcji.
