<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">ср, 20 сент. 2017 г. в 17:08, Sandro Santilli <<a href="mailto:strk@kbt.io">strk@kbt.io</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Sep 19, 2017 at 05:18:51AM -0700, Paul Ramsey wrote:<br>
> I'm generally in favor of the GUC, and to some extent in favor of having it<br>
> turned on by default, though I could stand a release cycle with it off for<br>
> testing purposes. I don't think we want the granularity of declaring<br>
> precision by table or by feature.<br>
<br>
A GUC for enabling it and GUC for specifying a precision GRID ?<br>
Or letting precision GRID being figured out by GEOS internally ?<br></blockquote><div><br></div><div>I am strongly against a GUC that will change precision.<br>We already have a switch for GEOS/CGAL backend, so a similar one for enabling (or disabling) FIXED mode is fine.</div><div><span style="color:rgb(0,0,0)"> </span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I generally think that precision would be a characteristic of<br>
a data rather than session.<br></blockquote><div> </div><div>There is a PR on validity flag for CGAL. This is a similar algorithm input characteristic, that should be stored in geometry, if cannot be effeciently calculated each time. And in general it can't - ST_SnapToGrid(geom, pi()) will make it a 3.14... meter grid, with all the last bits mostly set.</div></div></div>