Question

I have an application that I’ve been working on and found a troubling difference tonight – and I thought I would document it here and see if anyone can replicate it and/or explain it. The query is made up, but demonstrates the problem:

select 
    '123' ~ '^\d+$' as result_1, 
    '123' ~ '^[0-9]+$' as result_2

I have a PostgreSQL v9.1 running on Windows 7 and when I run this query I get:

T, T

However, when I run the query on PostgreSQL v9.0 on a Ubuntu 10.04 I get:

F, T

So, it would appear that either PostgreSQL changed between v9.0 and v9.1 in its handling of “\d” or it has something to with differences between the libs that got installed between Windows and Ubuntu.

Either way, I think that folk should be aware that your check constraints, etc might not behave the same between the two (mine sure didn’t).

Note: unfortunately, I don’t have easy access to a Windows 7 box running 9.0 or I would test it there, also.

Can anyone explain this? If it’s well known, please forgive me. I didn’t see an answer when I googled for it. Obviously the safe thing to do is to just use [0-9] because it works in both locations. But, again, I would like to know why this is happening.

Answer 1

You have an escaping problem. From the fine 9.1 manual on string quoting:

If the configuration parameter standard_conforming_strings is off, then PostgreSQL recognizes backslash escapes in both regular and escape string constants. However, as of PostgreSQL 9.1, the default is on, meaning that backslash escapes are recognized only in escape string constants.

So 9.1 sees '\d' the same way C does so it just looks like 'd'. In 9.1 you’d want to escape your backslash and use the E'' “escape” string notation to get past standard_conforming_strings:

select 
    '123' ~ E'^\\d+$' as result_1, 
    '123' ~ '^[0-9]+$' as result_2

Or you could try dollar quoting:

select 
    '123' ~ $re$^\d+$$re$ as result_1, 
    '123' ~ '^[0-9]+$' as result_2

but that’s pretty ugly and difficult to read with a regex (especially a regex that uses $ to anchor the end).

Another option would be to use a POSIX character class instead of \d:

select 
    '123' ~ '^[[:digit:]]+$' as result_1, 
    '123' ~ '^[0-9]+$' as result_2

You should have been seeing warnings about '\d' in earlier versions as well, check your logs for things like this:

WARNING:  nonstandard use of escape in a string literal
LINE 1: select '\d';
               ^
HINT:  Use the escape string syntax for escapes, e.g., E'\r\n'.