Tom,<br /><br />Thanks for your reply. So is the group leaning towards just maintaining the current regex code base,
orlooking into introducing a new library (RE2, PCRE, etc)? Or is this still open for discussion?<br /><br
/>Thanks!<br/><br />Billy<br /><br /><div class="gmail_quote">On Mon, Feb 20, 2012 at 3:35 PM, Tom Lane <span
dir="ltr"><<ahref="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Billy Earney
<<ahref="mailto:billy.earney@gmail.com">billy.earney@gmail.com</a>> writes:<br /> > Also would it be possible
toset a session variable (lets say PGREGEXTYPE)<br /> > and set it to ARE (current alg), RE2, or PCRE, that way
userscould choose<br /> > which implementation they want (unless we find a single implementation that<br /> >
beatsthe others in almost all categories)? Or is this a bad idea?<br /><br /></div>We used to have a GUC that selected
thedefault mode for Spencer's<br /> package (ARE, ERE, or BRE), and eventually gave it up on the grounds<br /> that it
didmore harm than good. In particular, you really cannot treat<br /> the regex operators as immutable if their
behaviorvaries depending on<br /> a GUC, which is more or less fatal from an optimization standpoint.<br /> So I'd say
aGUC that switches engines, and thereby brings in subtler<br /> but no less real incompatibilities than the old one
did,would be a<br /> pretty bad idea.<br /><br /> Also, TBH I have exactly zero interest in supporting pluggable
regex<br/> engines in Postgres. Regex is not sufficiently central to what we do<br /> to justify the work of coping
withN different APIs and sets of<br /> idiosyncrasies. (Perl evidently sees that differently, and with some<br />
reason.)<br/><br /> regards, tom lane<br /></blockquote></div><br />