Harald Fuchs <hari.fuchs@xxxxxxxxx> writes:
> Tom Lane <tgl@xxxxxxxxxxxxx> writes:
>> Julian Mehnle <julian@xxxxxxxxxx> writes:
>>> So far, so good. However, can someone please explain the following to me?
>>> wisu-dev=# SELECT regexp_matches('quux@foo@bar.zip', '([@.]|[^@.]+)+', 'g');
>>> wisu-dev=# SELECT regexp_matches('quux@foo@bar.zip', '([@.]|[^@.]+){1,2}', 'g');
>>> wisu-dev=# SELECT regexp_matches('quux@foo@bar.zip', '([@.]|[^@.]+){1,3}', 'g');
>> These might be a bug, but the behavior doesn't seem to me that it'd be
>> terribly well defined in any case. The function should be pulling the
>> match to the parenthesized subexpression, but here that subexpression
>> has got multiple matches --- which one would you expect to get?
> Perl seems to return always the last one, but the last one is never just
> 'p' - so I also think that Julian has spotted a bug.
Well, Perl is not the definition of correct regexp behavior ;-). It's
got a completely different regexp engine in it, and so you shouldn't
be surprised if a poorly-specified regexp gives different results.
(The regexp engine we use was borrowed from Tcl, not Perl. It has
some strengths and some weaknesses compared to Perl's.)
It does appear that our engine agrees with Perl's that the thing to do
with something like this is to return the last substring matching the
quantified expression. However, it appears to define that as the last
possible match, not what would be left over after removing the first N-1
matches left-to-right. It's possible to match the parenthesized
subexpression to just the trailing 'p', which is what it tries first,
and so that's what you get.
The right way to deal with this, I think, is to add constraints so that
the boundaries for the sub-matches are not ambiguous. Try adding
(?![^@.]) after the [^@.]+.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
