U hoeft niet te ontsnappen aan - binnen tekenklassen wanneer je het op de eerste of laatste positie plaatst, omdat het op die manier niet verkeerd kan worden gelezen als bereik:
[\- ] -> [- ] [\d\- ] -> [\d -]
Zoals jij het hebt de bovengrens 10 aan het einde is zinloos.
Voeg $ toe aan het einde om volgtekens niet toe te staan.
Of \D om achterliggende cijfers niet toe te staan (maar vereisen een niet-cijfer).
Of ($|\D) om de string daar te beëindigen of om een niet-cijferig vervolg te krijgen.
Samengevoegd:
SELECT '+79637434199' ~ '^(8|\+7)[ -]?(\(?\d{3}\)?[ -]?)[\d -]{7,10}($|\D)'
Anders is je expressie prima en werkt het voor mij op PostgreSQL 9.1.4. Het zou geen enkel verschil moeten maken of je het gebruikt in een WHERE clausule of in een SELECT lijst - tenzij u een bug tegenkomt met een oude versie (zoals @kgrittn gesuggereerd in de opmerkingen).
Als ik de letterlijke tekenreeks voorzet met E , kan ik de foutmelding uitlokken die je krijgt. Dit kan niet leg je probleem uit, want je hebt aangegeven dat de uitdrukking prima werkt als SELECT artikel.
Maar, zoals Sherlock Holmes wordt geciteerd, "wanneer je het onmogelijke hebt uitgesloten, moet alles wat overblijft, hoe onwaarschijnlijk ook, de waarheid zijn."
Misschien heb je één test uitgevoerd met standard_conforming_strings = on
en de andere met standard_conforming_strings = off - dit was de standaardinterpretatie van letterlijke tekenreeksen in oudere versies vóór 9.1. Misschien met twee verschillende clients (die daar een andere instelling voor hebben).
Lees meer in het hoofdstuk Stringconstanten met ontsnappingen in C-stijl in de handleiding.