Du behöver inte escape - inuti teckenklasser när du sätter den på den första eller sista positionen, eftersom den inte kan misstolkas som intervall på det sättet:
[\- ] -> [- ] [\d\- ] -> [\d -]
Som du har det är den övre gränsen 10 i slutet är meningslöst.
Lägg till $ i slutet för att inte tillåta efterföljande tecken.
Eller \D för att inte tillåta efterföljande siffror (men kräver en icke-siffrig).
Eller ($|\D) att antingen avsluta strängen där eller ha en icke-siffrig följ.
Sätt ihop:
SELECT '+79637434199' ~ '^(8|\+7)[ -]?(\(?\d{3}\)?[ -]?)[\d -]{7,10}($|\D)'
Annars är ditt uttryck bara bra och det fungerar för mig på PostgreSQL 9.1.4. Det borde inte göra någon som helst skillnad om du använder det i en WHERE sats eller i en SELECT lista - såvida du inte stöter på en bugg med någon gammal version (som @kgrittn föreslog i kommentarerna).
Om jag lägger E före strängen bokstavligt , jag kan provocera fram felmeddelandet som du får. Detta kan inte förklara ditt problem, eftersom du sa att uttrycket fungerar bra som SELECT objekt.
Men, som Sherlock Holmes citeras, "när du har uteslutit det omöjliga, måste det som återstår, hur osannolikt det än är, vara sanningen."
Du kanske körde ett test med standard_conforming_strings = on
och den andra med standard_conforming_strings = off - detta var standardtolkningen av strängliteraler i äldre versioner före 9.1. Kanske med två olika klienter (som har olika inställningar för det).
Läs mer i kapitlet Strängkonstanter med C-style Escapes i manualen.