Re: Another regexp performance improvement: skip useless paren-captures
От
Mark Dilger
Тема
Re: Another regexp performance improvement: skip useless paren-captures
Дата
Msg-id
1303A200-4615-4559-961A-CC906DE07EAF@enterprisedb.com
Ответ на
Список
Дерево обсуждения
Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Andrew Dunstan <andrew@dunslane.net>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Mark Dilger <mark.dilger@enterprisedb.com>
Re: Another regexp performance improvement: skip useless paren-captures Robert Haas <robertmhaas@gmail.com>
Re: Another regexp performance improvement: skip useless paren-captures Andrew Dunstan <andrew@dunslane.net>
Re: Another regexp performance improvement: skip useless paren-captures Tom Lane <tgl@sss.pgh.pa.us>
> On Aug 9, 2021, at 4:31 PM, Tom Lane wrote:
>
> This patch should work OK in HEAD and v14, but it will need
> a bit of fooling-about for older branches I think, given that
> they fill v->subs[] a little differently.
Note that I tested your patch *before* master, so the changes look backwards.
I tested this fix and it seems good to me. Some patterns that used to work (by chance?) now raise an error, such as:
select 'bpgouiwcquu' ~ '(((([e])*?)){0,0}?(\3))';
-ERROR: invalid regular expression: invalid backreference number
+ ?column?
+----------
+ f
+(1 row)
I ran a lot of tests with the patch, and the asserts have all cleared up, but I don't know how to think about the user facing differences. If we had a good reason for raising an error for these back-references, maybe that'd be fine, but it seems to just be an implementation detail.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления
От: Mark Dilger
Дата: