Re: WIP: proof of concept patch for fixing quantified regex backrefs - Mailing list pgsql-hackers

From Robert Haas
Subject Re: WIP: proof of concept patch for fixing quantified regex backrefs
Date
Msg-id CA+Tgmob+Ux4xFBcpsNxvxnt5SQo2MBb8U+F8ZHEXP2xEj3dNpg@mail.gmail.com
Whole thread Raw
In response to WIP: proof of concept patch for fixing quantified regex backrefs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Feb 22, 2012 at 11:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Attached is as far as I've gotten with fixing depesz's complaint about
> backrefs embedded within larger quantified expressions (the complaint
> being that only the last match of the backref is checked properly).
> This is per the analysis I posted at
> https://sourceforge.net/tracker/index.php?func=detail&aid=1115587&group_id=10894&atid=110894
> to the effect that the engine really has to have an "iteration" subre
> type.
>
> The patch is incomplete because I have not written the code yet for the
> shortest-match-first case, only longest-match-first.  Within that
> restriction, it seems to work, though I have not yet tried the Tcl
> regression tests on it.
>
> I have to set this aside now and go focus on release tasks (like writing
> release notes), so it's not going to be done in time to include in the
> upcoming back-branch releases.  I have mixed feelings about whether to
> treat it as a back-patchable bug fix when it's done ... it's certainly a
> bug fix but the odds of introducing new issues seem higher than average.
> So maybe it should only go into HEAD anyway.  Thoughts?

+1 for just doing it in HEAD.  This strikes me as the sort of thing
that has a higher-than-average chance of breaking applications in
subtle ways, and that's exactly the sort of thing that we don't want
to do in a minor release, especially in older branches where people
are presumably not upgrading precisely because what they have today
works for them.  If someone really needs the fix, they can always
back-port it themselves... I don't think that code has changed much.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_upgrade --logfile option documentation
Next
From: Peter Geoghegan
Date:
Subject: Re: 16-bit page checksums for 9.2