Fix for bug #1629

[Daniel Morissette]

Umberto Nicoletti wrote:
> I have checked out HEAD and verified on a map of my own the the bug
> exists by defining both FILTER and FILTERITEM on a layer. If I removed
> the FILTERITEM then the map worked again as expected.
> 
> Then I have applied my patch and verified that the map worked again with:
> -both FILTER and FILTERITEM
> -only with FILTER
> -only with FILTERITEM
> 
> I used the following values in the test:
> 
> FILTER = ' myattribute=A OR myattribute=B '
> FILTERITEM='myattribute'
> 
> Last but not least I checked the Oracle spatial code and can confirm
> (If I understood correctly) that the behaviour of postgis with my
> patch matches that of Oracle Spatial, that is the FILTERITEM is 
> ignored (as the docs say).
> 
> To be frank I have not tested using msSearchByAttribute because that
> would have required some more time (which I really do not have) but
> for what I know they should end up calling the same functions, so the
> tests are to be considered valid.
> 
> I hope this answers your question.
> 

Um... I was more hoping for a "yes it's safe and if I'm wrong then I owe 
each of you a beer for having delayed the release" type of answer. ;)

I am not familiar enough with the mappostgis.c implementation to tell 
whether there is potential for side-effects so I have to conclude that 
it's not safe to backport this a few days before the release.

> Note 1: we should really set up some automated tests for stuff like
> this and in particular for regression testing and integrate them in
> the build process.
> 

Agreed. Does this mean you're offering to contribute some tests for Sean 
or Frank's test suites? ;)

> Note 2: I think that we should delay 4.8: better late but working than
> in time but with errors.
> 

I really think it's been delayed enough, we're already 6 weeks passed 
the original date and it's not like this bug affects a large number of 
users anyway, right? How about we document the issue for 4.8.0 and 
backport the fix to 4.8.1?

Sorry to be a pain, it's not your fault specifically, but I've been 
reminded a few days ago that I have been too easy as release manager 
this time in letting last minute stuff sneak in and betas end up late, 
which caused this 6 weeks release delay... and I think the comment was 
legitimate, so we're getting back on track with the 4.8.0 release 
tomorrow unless I hear strong objections.

Daniel
-- 
------------------------------------------------------------
  Daniel Morissette               dmorissette at dmsolutions.ca
  DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------