On Wed, Apr 18, 2012 at 11:39:44AM +0200, Jose Carlos Martinez wrote: > >I've asked Regina some time ago to play a bit with an SQL implementation > >of && operator. Theoretically an SQL implementation could be inlined > >and as such could be using indices on the primitive tables. > > You re talking about a functional index?
Nope, I was talking about using indices on tables containing the primitives rather than on tables containing the TopoGeometries. > s1=# create index test on suelos using gist (st_envelope(topogeom)); > ERROR: functions in index expression must be marked IMMUTABLE > > Even St_envelope is immutable I think its not working because > converting from topogeom to geometry needs reading for other tables > so it can not be immutable That's the reason for it to not be IMMUTABLE. But I guess it would "work" if you mark it as such. Only you won't have the update index on updated TopoGeometry semantic. An interesting research topic could be about how to notify TopoGeometry objects about changes occurred in the underlying table. We should have all information we need to find the TopoGeometry objects (so we could do a faked UPDATE or something like that to force re-indexing). > I will keep trying to study and to help you if I can. I think > topology is a very attractive field for teaching and researching. Great, looking forward for more contributions :) Beside, since you're looking at ST_Intersection, it may be worth adding a testcase for it as I'm pretty sure it has some unwanted side effects like throwing an exception when passed TopoGeometry objects from different topologies... --strk; ,------o-. | __/ | Delivering high quality PostGIS 2.0 ! | / 2.0 | http://strk.keybit.net - http://vizzuality.com `-o------' _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
