Re: Future of our regular expression code

Tom,

Thanks for your reply. So is the group leaning towards just maintaining
the current regex code base, or looking into introducing a new library
(RE2, PCRE, etc)? Or is this still open for discussion?

Thanks!

Billy

On Mon, Feb 20, 2012 at 3:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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
>