Peter Eisentraut <peter_e@gmx.net> 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