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
> to the effect that the engine really has to have an "iteration" subre
> 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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Timothy Garnett||Date: 2012-02-22 23:17:31|
|Subject: Option for pg_dump to dump tables in clustered index order|
|Previous:||From: Robert Haas||Date: 2012-02-22 22:49:26|
|Subject: Re: pg_upgrade --logfile option documentation|