Non è necessario eseguire l'escape - all'interno delle classi di caratteri quando lo metti nella prima o nell'ultima posizione, perché non può essere interpretato erroneamente come intervallo in questo modo:
[\- ] -> [- ] [\d\- ] -> [\d -]
Il modo in cui lo hai il limite superiore 10 alla fine è inutile.
Aggiungi $ alla fine per non consentire i caratteri finali.
Oppure \D per non consentire cifre finali (ma richiede una cifra diversa da quella).
Oppure ($|\D) per terminare lì la stringa o avere un seguito senza cifre.
Metti insieme:
SELECT '+79637434199' ~ '^(8|\+7)[ -]?(\(?\d{3}\)?[ -]?)[\d -]{7,10}($|\D)'
Altrimenti la tua espressione va bene e funziona per me su PostgreSQL 9.1.4. Non dovrebbe fare alcuna differenza se lo usi in un WHERE clausola o in un SELECT list - a meno che tu non stia riscontrando un bug con qualche vecchia versione (come @kgrittn suggerito nei commenti).
Se antepongo la stringa letterale con E , posso provocare il messaggio di errore che ricevi. Questo non può spiega il tuo problema, perché hai affermato che l'espressione funziona bene come SELECT elemento.
Ma, come viene citato Sherlock Holmes, "quando hai escluso l'impossibile, tutto ciò che rimane, per quanto improbabile, deve essere la verità".
Forse hai eseguito un test con standard_conforming_strings = on
e l'altro con standard_conforming_strings = off - questa era l'interpretazione predefinita delle stringhe letterali nelle versioni precedenti prima della 9.1. Forse con due client diversi (che hanno un'impostazione diversa).
Maggiori informazioni nel capitolo Costanti stringa con escape in stile C nel manuale.
