вт, 10 июл. 2018 г. в 8:18, Pavan Deolasee <[email protected]>:
> 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. > Text representation of geography is given from above, https://en.wikipedia.org/wiki/Well-known_text#Well-known_binary > > 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. > What you can try is to short-circuit ST_Expand to ST_Buffer for now. It's more expensive computationally, but for most practical use cases the box it produces should be similar to that of ST_Expand, and serialized geometry should produce the same box on both sides of serialization. > > Any help is highly welcome. > > Thanks, > Pavan > > -- > Pavan Deolasee http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > _______________________________________________ > postgis-devel mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/postgis-devel
_______________________________________________ postgis-users mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/postgis-users
