Jeevan Chalke <jeevan.cha...@enterprisedb.com> writes:
> Following example does not work as expected:
> -- Should return TRUE but returning FALSE
> SELECT 'Programmer' ~ '(\w).*?\1' as t;
This is clearly broken, but I'm uncomfortable with the proposed patch.
As written, it changes behavior for both the shortest-match-preferred
and longest-match-preferred cases; but you've offered no evidence that
the longest-match case is broken. Maybe it is --- it's sure not
obvious why it's okay to abandon the search early in this case. But I
think we'd have been likely to hear about it before now if there were
a matching failure in that path, since longest-preferred is so much
more widely used.
I think we should either convince ourselves that the longest-preferred
case is also broken (preferably with a test case), or understand why it
isn't. Such understanding would probably also teach us how to fix the
shortest-preferred case in a way that doesn't give up early search exit.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
