Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> code is concerned: the regex library actually offers three regex >> flavors, "advanced", "extended", and "basic", where "extended" matches >> what we had before ("extended" and "basic" correspond to different >> levels of the POSIX 1003.2 standard). We just need a way to expose >> that knob to the user. I am thinking about inventing yet another GUC >> parameter, say
> Perhaps it should be exposed through different operators. If someone uses > packages (especially functions) provided externally, they might have a > hard time coordinating what flavor is required by which part of what he is > using. But one could argue the contrary, too: if you've got an externally-provided package there may be no convenient way to get it to use, say, ~!#@ in place of ~. GUC variables can come in awfully handy in scenarios like that. Also, if one *can* alter the SQL context in which a regexp is used, there is a solution already provided by Spencer's "regex metasyntax" hack --- see http://developer.postgresql.org/docs/postgres/functions-matching.html#POSIX-METASYNTAX That is, one could write something like foo ~ ('(?b)' || basic_regex_expression) to force basic_regex_expression to be taken as a BRE and not the extended syntax. This is a tad uglier than changing the operator name, perhaps, but it has some advantages too --- for one, the option could be plugged into the string further upstream than where the SQL syntax is determined. Basically I think the flavor-as-GUC-variable approach is orthogonal to inventing some new operator names. We could do the latter too, but I don't really see a need for it given the metasyntax feature. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]