Thread: Regex "embedded options" does only work on the whole pattern?
Hi,
I can see postgresql claims to supports regular expression flags:
http://www.postgresql.org/docs/current/static/functions-matching.html#POSIX-EMBEDDED-OPTIONS-TABLE
which I suppose aims to be the equivalent of perl's
(?adluimsx-imsx:pattern)What I find don't makes sense to me is that those flags could be used to switch on/off match feature locally as opposed to the whole regex (same as though flags parameters of regex functions).
Perl supports that locality while postgres documentation says:
"An ARE can begin with embedded options: a sequence (?xyz) (where xyz is one or more alphabetic characters) specifies options affecting the rest of the RE. These options override any previously determined options — in particular, they can override the case-sensitivity behavior implied by a regex operator, or the flags parameter to a regex function.
"
Does that mean these "EMBEDDED OPTIONS" can be only defined at the beginning of the pattern and therefore don't offer anything extra over flags option?
By the looks of the table it seems postgres supports locality ("rest of RE" in description for b, e, q option)
I tried to switch case insensitieness with "(?i)" in the middle of the pattern but I'm getting:
********** Error **********
ERROR: invalid regular expression: quantifier operand invalid
SQL state: 2201B
When I do "(?i)" at the beginning of the pattern it works but then applies to the whole pattern.
Any ideas?
Thank you,
Kind Regards
~Msciwoj
Does that mean these "EMBEDDED OPTIONS" can be only defined at the beginning of the pattern and therefore don't offer anything extra over flags option?
Yes, this is how they behave. The most important difference is that:
column ~ 'regex' (i.e., the operator)
can only accept embedded switches since there is no place to write a formal flag like you can with the functions.
Though there is a case-insensitive operator as a usability feature the other modes lack any external operator support.
David J.
matshyeq <matshyeq@gmail.com> writes:
> I can see postgresql claims to supports regular expression flags:
Yup.
> What I find don't makes sense to me is that those flags could be used to
> switch on/off match feature locally as opposed to the whole regex (same as
> though flags parameters of regex functions).
Not all of them would make sense locally; in fact I'd venture that
case-sensitivity is the *only* flag that anyone would consider using
that way.
> Perl supports that locality while postgres documentation says:
> "*An ARE can begin with embedded options: a sequence (?xyz) (where xyz is
> one or more alphabetic characters) specifies options affecting the rest of
> the RE.
Right. It says "begin with" and it means "begin with".
We are not Perl and are not attempting to be bug-compatible with its regex
engine. If you want bug-compatibility, see PL/Perl.
regards, tom lane
Makes sense.
Thank you both for clarifications!
Was only wondering if this feature is there so I could elegantly do equivalent of perl's (small 'a', anycase 'sd', small 'f'):
$,="\n";
my $testr='1asdf
2AsdF
3AsDF
4asDf
5aSDf
6aSdf
7ASdf
8Asdf';
my @res = $testr =~ /a(?i:sd)f/g;
print @res;
-----
asdf
asDf
aSDf
aSdf
Thank you,
Kind Regards
~Maciek
On 4 January 2016 at 03:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
matshyeq <matshyeq@gmail.com> writes:
> I can see postgresql claims to supports regular expression flags:
Yup.
> What I find don't makes sense to me is that those flags could be used to
> switch on/off match feature locally as opposed to the whole regex (same as
> though flags parameters of regex functions).
Not all of them would make sense locally; in fact I'd venture that
case-sensitivity is the *only* flag that anyone would consider using
that way.
> Perl supports that locality while postgres documentation says:
> "*An ARE can begin with embedded options: a sequence (?xyz) (where xyz is
> one or more alphabetic characters) specifies options affecting the rest of
> the RE.
Right. It says "begin with" and it means "begin with".
We are not Perl and are not attempting to be bug-compatible with its regex
engine. If you want bug-compatibility, see PL/Perl.
regards, tom lane