Re: Future of our regular expression code

Billy Earney <billy(dot)earney(at)gmail(dot)com> writes:
> Also would it be possible to set a session variable (lets say PGREGEXTYPE)
> and set it to ARE (current alg), RE2, or PCRE, that way users could choose
> which implementation they want (unless we find a single implementation that
> beats the others in almost all categories)? Or is this a bad idea?

We used to have a GUC that selected the default mode for Spencer's
package (ARE, ERE, or BRE), and eventually gave it up on the grounds
that it did more harm than good. In particular, you really cannot treat
the regex operators as immutable if their behavior varies depending on
a GUC, which is more or less fatal from an optimization standpoint.
So I'd say a GUC that switches engines, and thereby brings in subtler
but no less real incompatibilities than the old one did, would be a
pretty bad idea.

Also, TBH I have exactly zero interest in supporting pluggable regex
engines in Postgres. Regex is not sufficiently central to what we do
to justify the work of coping with N different APIs and sets of
idiosyncrasies. (Perl evidently sees that differently, and with some
reason.)

regards, tom lane