Thread

1. WIP: proof of concept patch for fixing quantified regex backrefs

   Tom Lane <tgl@sss.pgh.pa.us> — 2012-02-22T16:19:13Z

   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?
   
   			regards, tom lane
   
   
   

2. Re: WIP: proof of concept patch for fixing quantified regex backrefs

   Robert Haas <robertmhaas@gmail.com> — 2012-02-22T22:57:05Z

   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