Re: text_pattern_ops and complex regexps - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: text_pattern_ops and complex regexps
Date
Msg-id 20090506161049.GE4476@alvh.no-ip.org
Whole thread Raw
In response to Re: text_pattern_ops and complex regexps  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: text_pattern_ops and complex regexps  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: text_pattern_ops and complex regexps  (David Fetter <david@fetter.org>)
Re: text_pattern_ops and complex regexps  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: text_pattern_ops and complex regexps  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:

> > Perhaps this is misguided but I would think that the regexp
> > libraries might have some support for "give me all anchored required
> > text for this regexp" which we could then use in the planner.
> 
> I wouldn't see why.  It's certainly worth considering to hand the
> pattern to the regex engine and then burrow into the data structure it
> builds; but right now we consider that structure to be entirely private
> to backend/regex/.  There's also the problem that we'd have no easy
> way to determine how much the result depends on the current regex flavor
> setting.  There are some cases now where regex_fixed_prefix deliberately
> omits possible optimizations because of uncertainty about the flavor.

I think changeable regex flavors turned out to be a bad idea.  They can
wreak all sorts of havoc.  You change the setting, SIGHUP, and suddenly
your application fails to work as expected.  Maybe we should make that
setting PGC_POSTMASTER (or just get rid of it?), and provide was to pass
flags to change the flavor for particular operations (this is easy for
function-based stuff but not so easy for operators).  That way it
doesn't intrude in stuff like cached plans and so on.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: bytea vs. pg_dump
Next
From: Tom Lane
Date:
Subject: Re: text_pattern_ops and complex regexps