On Thu, Jul 5, 2018 at 6:47 PM, Pavan Deolasee <[email protected]> wrote:
> > > > While I look at the XL side more carefully and see if we can revert back > to PG's behaviour, I still believe this is a problem that we should fix on > the PostGIS side (too). AFAIK in PostgreSQL we assume that out/in functions > should safely convert a value to a string and back to its in-memory > representation. So keeping that guarantee for the "geography" data type > seems like the right thing to do. > > Any feedback here? I am willing to write a patch if the community guides me in the right direction. My knowledge of PostGIS is quite limited and I am not sure if changing the text representation of the geography type is acceptable. BTW I tried to work around this problem by patching ST_DWithin(geography, float) so that the overlap is checked inside the C function. While that fixes the problem at hand, it regresses the query planning because planner can no longer see those additional quals and switches from an index scan to a seq scan. So I'd to abandon that approach. Any help is highly welcome. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
_______________________________________________ postgis-users mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/postgis-users
