Opened 15 years ago
Closed 7 years ago
#407 closed enhancement (wontfix)
Use PgSQL globals to define number of output digits to print
Reported by: | pramsey | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS Fund Me |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
For WKT output and others (?) we can use the PgSQL DBL_DIG and the runtime extra_float_digits parameter to determine how much precision to output?
http://www.postgresql.org/docs/current/static/runtime-config-client.html
Change History (5)
comment:1 by , 15 years ago
comment:2 by , 14 years ago
As an aside, see #584 for a potential benefit of this feature. We should set extra_float_digits to -2 or -4 at the start of the regression run to try and squeeze out precision difference noise from the regression test runs.
We can't remove the precision parameter from the function signatures in liblwgeom, unfortunately, since we don't have access to the GUC at that level, only at the database level. If we were willing to put the output precision into a liblwgeom global we could, but then liblwgeom would not be thread-safe.
Do we care? maybe, if we plan on multi-threading it some day. On the other hand, the parser is currently not re-entrant, and I don't actually plan on making the new one re-entrant since it involves learning even more about bison and lex!
comment:3 by , 13 years ago
Milestone: | PostGIS 2.0.0 → PostGIS Future |
---|
sounds too hard for the benefit
comment:5 by , 7 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
so many implications, not going to happen
Yes, sounds good to homogenize behaviour with other ST_As* functions. We could remove the precision parameter used for them.
Nota: current ST_As* use trim_trailing_zeros, and that's a good think to keep.