Andrew Dunstan writes:
> Tom Lane wrote:
>> Is this demonstrable, or just speculation? The incompatibilities
>> between ARE mode and (legal) ERE patterns are pretty darn small.
> It's explicitly documented. Whether or not there is a good basis for the
> documentation I can't yet say. If that's
Tom Lane wrote:
Andrew Dunstan writes:
I know of at least one significant client (OpenACS) that still
apparently requires extended flavor.
Is this demonstrable, or just speculation? The incompatibilities
between ARE mode and (legal) ERE patterns are pretty darn small.
Alvaro Herrera writes:
> ... Maybe we should make that
> setting PGC_POSTMASTER (or just get rid of it?),
Another thought here: if we do get persuaded that the regex_flavor GUC
has to stay, we could eliminate it as a hazard for planning by changing
its scope to PGC_BACKEND. That would be much l
Andrew Dunstan writes:
> I know of at least one significant client (OpenACS) that still
> apparently requires extended flavor.
Is this demonstrable, or just speculation? The incompatibilities
between ARE mode and (legal) ERE patterns are pretty darn small.
regards, tom
On Wed, 2009-05-06 at 16:10 -0400, Andrew Dunstan wrote:
> > Isn't that why we wouldn't remove it from back releases?
> >
> >
>
> My clients aren't going to be very happy if they can't upgrade because
> of this.
Certainly. Nobody wants to make clients unhappy but for the good of the
code ma
Joshua D. Drake wrote:
On Wed, 2009-05-06 at 15:55 -0400, Andrew Dunstan wrote:
I know of at least one significant client (OpenACS) that still
apparently requires extended flavor. Removing the compatibility option
would be a major pain point for some of my clients. PGC_POSTMASTER would
b
On Wed, 2009-05-06 at 15:55 -0400, Andrew Dunstan wrote:
> I know of at least one significant client (OpenACS) that still
> apparently requires extended flavor. Removing the compatibility option
> would be a major pain point for some of my clients. PGC_POSTMASTER would
> be fine, though.
Isn't
Tom Lane wrote:
Alvaro Herrera writes:
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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> If we think there aren't any of those anymore, let's just kill the
> GUC and be done with it.
+1.
I'll try to spend some time in backend/regexp and regex_fixed_prefix
soon.
Thanks,
Stephen
signature.asc
Description: Digital si
Alvaro Herrera writes:
> ... 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).
BTW, if you are putting it on the appli
Tom Lane wrote:
Alvaro Herrera writes:
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 o
On Wed, May 06, 2009 at 12:10:49PM -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Stephen Frost 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 the
Alvaro Herrera writes:
> 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
Tom Lane wrote:
> Stephen Frost 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 conside
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> (In particular, I think it's set up to abandon optimization if it
>> sees | anywhere.)
> That's kind of what I figured from the empirical data. My hope was that
> it might be something which could be fixed.
See regex_fixed_prefix
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I don't see why the last case can't use the index.
>
> The planner's understanding of regexps is far weaker than yours.
>
> (In particular, I think it's set up to abandon optimization if it
> sees | anywhere.)
That's kind of w
Stephen Frost writes:
> I don't see why the last case can't use the index.
The planner's understanding of regexps is far weaker than yours.
(In particular, I think it's set up to abandon optimization if it
sees | anywhere.)
regards, tom lane
--
Sent via pgsql-hackers
Greetings,
I've run into an annoying issue which I would think could be handled
better. Basically, indexes using text_pattern_ops don't work with
some complex regexps even when they (imv anyway) could. I'm willing
to believe I'm wrong about the potential to use them, or that my
regexp
18 matches
Mail list logo
