Re: BUG #6760: make check fails on strings SQL T581 regex test
От | Tom Lane |
---|---|
Тема | Re: BUG #6760: make check fails on strings SQL T581 regex test |
Дата | |
Msg-id | 29371.1343236215@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #6760: make check fails on strings SQL T581 regex test (jez.wain@bull.net) |
Ответы |
Re: BUG #6760: make check fails on strings SQL T581 regex test
|
Список | pgsql-bugs |
jez.wain@bull.net writes: > *************** > *** 347,354 **** > three | f1 | exp_ln_f1 > -------+----------------------+----------------------- > | 1004.3 | 1004.3 > ! | 1.2345678901234e+200 | 1.23456789012338e+200 > ! | 1.2345678901234e-200 | 1.23456789012339e-200 > (3 rows) > -- cube root > --- 347,354 ---- > three | f1 | exp_ln_f1 > -------+----------------------+----------------------- > | 1004.3 | 1004.3 > ! | 1.2345678901234e+200 | 1.23456789012337e+200 > ! | 1.2345678901234e-200 | 1.2345678901234e-200 > (3 rows) This doesn't seem terribly surprising as a platform-specific difference. > -- T581 regular expression substring (with SQL99's bizarre regexp syntax) > SELECT SUBSTRING('abcdefg' FROM 'a#"(b_d)#"%' FOR '#') AS "bcd"; > ! ERROR: invalid regular expression: parentheses () not balanced > ! CONTEXT: SQL function "substring" statement 1 This however isn't too good. It suggests a platform-specific issue in the regex library, but hard to say what. Can you dig a little deeper, maybe get a stack trace back from the call to errfinish()? Does compiling with -O0 change the behavior? regards, tom lane
В списке pgsql-bugs по дате отправления: