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
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

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]

Reply via email to