Re: Future of our regular expression code - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Future of our regular expression code
Date
Msg-id 2475.1329773725@sss.pgh.pa.us
Whole thread Raw
In response to Re: Future of our regular expression code  (Billy Earney <billy.earney@gmail.com>)
Responses Re: Future of our regular expression code  (Billy Earney <billy.earney@gmail.com>)
List pgsql-hackers
Billy Earney <billy.earney@gmail.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


pgsql-hackers by date:

Previous
From: Billy Earney
Date:
Subject: Re: Future of our regular expression code
Next
From: Billy Earney
Date:
Subject: Re: Future of our regular expression code