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 <t...@sss.pgh.pa.us> wrote: > Billy Earney <billy.ear...@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 >
