On Tue, Oct 11, 2016 at 11:42:12AM +0200, Jürgen E. Fischer wrote:
> On Tue, 11. Oct 2016 at 10:45:18 +0200, Sandro Santilli wrote:
> > Chasing a regression bug upon importing shapefile to postgresql [1]
> > I've stumbled upon an unclear semantic of the "length" member of
> > QgsField class [2].
> Hm, I though that was following database semantics - at least that's what I
> recall - maybe it was changed.

By "database semantics" you mean PostgreSQL "numeric" semantic ?
PostgreSQL numeric has "precision" and "scale", where "precision"
is total number of digits (excluding comma) and "scale" is max number
of decimal digits (right of the comma, truncated as needed).

> Not sure OGR has a general semantic of it's own, maybe it follows the data
> source and those are inconsistent.

OGR provider decrements the length by one if precision is non-zero, upon 

And re-adds one upon writing (converting):

In both cases it does so by just looking at the presence of a non-zero
precision, regardless of datatype.

> For what I know in shapes and postgres the semantics is different as the
> decimal separator is considered part of the precision in one, but not the
> other.

According to this:

A DBF field with extended data type "double" does not affect the
precision of the stored data, and the length information is simply

After all, a "Double" in a DBF is just 8 bytes anyway, so why bother
attempting to go beyond that ? Qgis is storing values in a Double too,
and the only reason I see to support "numeric" is storing arbitrary
precision values, which don't seem to be supported by OGR:

Qgis-developer mailing list
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Reply via email to