From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, wade <wade(at)wavefire(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: POSIX regex performance bug in 7.3 Vs. 7.2 |
Date: | 2003-02-04 19:21:18 |
Message-ID: | 1044386478.19416.30.camel@huli |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2003-02-04 at 16:59, Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > Given that this problem isn't a regression, I don't think we need to
> > delay 7.3.2 to fix it (of course, a fix for 7.3.3 and 7.4 is essential,
> > IMHO).
>
> No, I've had to abandon my original thought that it was a localized bug,
> so it's not going to be fixed in 7.3.2.
>
> The real problem is simply that we're up against design limitations of
> the existing regex package, which was never designed for wider-than-8-bit
> character sets. It's been rather crudely hacked while it was in our
> hands (Henry Spencer would probably disown the code if he saw it now ;-))
> so that it sorta kinda does MULTIBYTE, but it's slow and I don't think
> it's complete either.
>
> I'm about to go off and look at whether we can absorb the Tcl regex
> package, which is Spencer's new baby.
Why not PCRE ( http://pcre.sourceforge.net/ ) ?
They claim at least utf-8 (I don't remember other multibyte charsets
being mentioned) support and have a BSD-ish license,
http://pcre.sourceforge.net/license.txt .
--
Hannu Krosing <hannu(at)tm(dot)ee>
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2003-02-04 19:29:27 | Re: POSIX regex performance bug in 7.3 Vs. 7.2 |
Previous Message | Tom Lane | 2003-02-04 19:18:24 | Re: POSIX regex performance bug in 7.3 Vs. 7.2 |