Du behøver ikke escape - inde i karakterklasser, når du placerer den på den første eller sidste position, fordi den ikke kan mislæses som rækkevidde på den måde:
[\- ] -> [- ] [\d\- ] -> [\d -]
Som du har det, er den øvre grænse 10 i slutningen er nytteløst.
Tilføj $ i slutningen for at ikke tillade efterfølgende tegn.
Eller \D for at ikke tillade efterfølgende cifre (men kræver et ikke-cifret).
Eller ($|\D) enten at afslutte strengen der eller have en ikke-cifret følge.
Sæt sammen:
SELECT '+79637434199' ~ '^(8|\+7)[ -]?(\(?\d{3}\)?[ -]?)[\d -]{7,10}($|\D)'
Ellers er dit udtryk helt fint, og det virker for mig på PostgreSQL 9.1.4. Det burde ikke gøre nogen som helst forskel, om du bruger det i en WHERE klausul eller i en SELECT liste - medmindre du løber ind i en fejl med en gammel version (som @kgrittn foreslået i kommentarerne).
Hvis jeg sætter strengen bogstavelig foran med E , jeg kan fremprovokere den fejlmeddelelse, du får. Dette kan ikke forklar dit problem, fordi du sagde, at udtrykket fungerer fint som SELECT vare.
Men, som Sherlock Holmes er citeret, "når du har udelukket det umulige, må det, der er tilbage, uanset hvor usandsynligt det end er, være sandheden."
Måske har du kørt en test med standard_conforming_strings = on
og den anden med standard_conforming_strings = off - dette var standardfortolkningen af strenge bogstaver i ældre versioner før 9.1. Måske med to forskellige klienter (der har forskellige indstillinger for det).
Læs mere i kapitlet Strengkonstanter med C-style Escapes i manualen.