Skip site navigation (1) Skip section navigation (2)

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: proof of concept patch for fixing quantified regex backrefs
Date: 2012-02-22 22:57:05
Message-ID: CA+Tgmob+Ux4xFBcpsNxvxnt5SQo2MBb8U+F8ZHEXP2xEj3dNpg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Feb 22, 2012 at 11:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

pgsql-hackers by date

Next:From: Timothy GarnettDate: 2012-02-22 23:17:31
Subject: Option for pg_dump to dump tables in clustered index order
Previous:From: Robert HaasDate: 2012-02-22 22:49:26
Subject: Re: pg_upgrade --logfile option documentation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group