Does this mean that at very least the function should for now be marked as PARALLEL RESRLTRICTED so that in case of parallel query value never goed through serialization? <br><br><div class="gmail_quote"><div dir="ltr">On ср, 4 ліп 2018, 06:27 Pavan Deolasee <<a href="mailto:pavan.deolasee@gmail.com">pavan.deolasee@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Paul,<div><br></div><div>Thanks for looking into it.</div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote"></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 3, 2018 at 11:41 PM, Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
When I look at what we do for geometry:<br>
<br>
select st_astext(st_expand('LINESTRING(0 0, 1 1)'::geometry, 1));<br>
<br>
POLYGON((-1 -1,-1 2,2 2,2 -1,-1 -1))<br>
<br>
Huh, we morph a linestring into a polygon, odd, right? But it's a<br>
polygon that represents the bounds.<br></blockquote><div><br></div></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>That makes sense in theory, though I admit I don't fully understand how a line segment gets expanded to a polygon of that shape. Naively I would have expected that each point on the polygon boundary to be at a distance of 1 unit from the line segment. But I remember only a few things from my geometry class :-)</div></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I start to think that perhaps the existing behavior is broken, and<br>
geography expand should rewrite the object so that it becomes<br>
something that has the 3-space bounds we want. Maybe an appropriately<br>
chosen multipoint, for example. It will be very confusing to people,<br>
though, since they tend to think rectangularly about bounds, even when<br>
working with spherical coordinates, which are very decidedly not<br>
rectangular.<br></blockquote><div><br></div></div></div></div></div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>Its a relief that you think that the existing behaviour is broken, otherwise I would have to look for ugly hacks in XL to fix this. But even outside XL, I think this could be a problem for PostGIS since a SQL expression may get evaluated, then converted into a string representation and later converted back into the in-memory representation, losing critical information on the way. So I think it's appropriate that we fix this in PostGIS. Would it be feasible to output the bounding box information in geography_out() and reconstructed back in the geography_in() function? </div><div><br></div><div>Thanks,</div><div>Pavan</div><div><br></div><div>P.S. Paul, I've distinct memories from your keynote at PGCon 2011, which I'd immensely liked. I did not get chance to congratulate you then, so here I am doing so after 7 years ;-)</div><div><br></div></div></div></div></div><div dir="ltr"><div><div class="gmail_extra">-- <br><div class="m_8933472211334071642m_5145443478210562452gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"> Pavan Deolasee <a href="http://www.2ndQuadrant.com/" target="_blank">http://www.2ndQuadrant.com/</a><br> PostgreSQL Development, 24x7 Support, Training & Services</div></div></div></div>
</div></div></div>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a></blockquote></div>