[postgis-devel] Query interruptibility in stable branch

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Fri Jun 8 06:07:46 PDT 2012


On 06/06/12 16:08, Paul Ramsey wrote:

> I have no objection to code that is #defined as disabled being added.
> In fact I wanted to add some (the new rtree splitting approach prior
> to 2.0) recently.  That being said, why not just maintain a branch at
> github with your changes for client purposes? I've done that (actually
> SVN spikes) many times in the past for folks on MapServer features.
>
> P.

Eh? This is actually the worst of both worlds because if it's disabled 
by default then it won't get the testing it requires, plus we've 
regressed to having more version-specific #ifdef-ery around. The reason 
I worked so hard around 1.4 to improve version detection and make 
dependencies compulsory was give users a more consistent experience, and 
thus ensure that once a patch passes regression, it's going to be 
reasonably safe.

While you could argue that this is not a bad thing, our track record on 
getting this right isn't great - I've lost count of the number of times 
during the 2.0 release cycle where I've had to fix #ifdef 
POSTGIS_GEOS_VERSION ... #endif on older GEOS versions we've said we 
support because they had been added but people obviously hadn't bothered 
to compile-test them.

Honestly - please let's just keep this in 2.1 branch and enable it by 
default there so it starts to get more testing. I've already conceded 
that we should have a short 2.1 development cycle so that you can get 
your RTree splitting changes in too. By putting new things in stable 
releases, we are just working against ourselves and making all our lives 
more difficult.


ATB,

Mark.



More information about the postgis-devel mailing list