Opened 13 years ago
Closed 13 years ago
#992 closed defect (fixed)
[raster] PostGIS raster && operator not installed when GSERIALIZED_ON
Reported by: | robe | Owned by: | pramsey |
---|---|---|---|
Priority: | blocker | Milestone: | PostGIS 2.0.0 |
Component: | raster | Version: | master |
Keywords: | Cc: |
Description (last modified by )
When GSERIALIZED is ON, raster && operator still built with geometry_gist_sel which is only valid for our non-GSERIALIZED.
Pierre et al,
Mind if I fix this one?
Change History (6)
comment:1 by , 13 years ago
Description: | modified (diff) |
---|---|
Summary: | PostGIS raster operators not installed when GSERIALIZED_ON → PostGIS raster && operator not installed when GSERIALIZED_ON |
comment:2 by , 13 years ago
Summary: | PostGIS raster && operator not installed when GSERIALIZED_ON → [raster] PostGIS raster && operator not installed when GSERIALIZED_ON |
---|
comment:3 by , 13 years ago
Owner: | changed from | to
---|
comment:4 by , 13 years ago
I didn't see this ticket before I made this exact change in r7394. With this change and a few more due to the maximum srid permitted in GSERIALIZED, the raster regressions pass (minus the existing issues with MapAlgebra).
Note:
See TracTickets
for help on using tickets.
Paul,
Maybe you should tackle this one or tell us what needs to be done here.
The issue is raster operator is defined like this:
My first thought was to include the gserialized header in there and then change to this to match the way you have geometry:
#ifdef GSERIALIZED_ON CREATE OPERATOR && (
#else CREATE OPERATOR && (
#endif
But I've never understood the difference between contsel and geometry_gist_sel and why I wouldn't just go with contsel, contjoinsel in both the GSERIALIZED ON/OF cases and then not have to include the header file.