[Qgis-developer] QgsField::length semantic

[Sandro Santilli]

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 reading:
https://github.com/qgis/QGIS/blob/master/src/providers/ogr/qgsogrprovider.cpp#L885

And re-adds one upon writing (converting):
https://github.com/qgis/QGIS/blob/master/src/providers/ogr/qgsogrprovider.cpp#L94

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:
http://devzone.advantagedatabase.com/dz/webhelp/advantage9.0/server1/dbf_field_types_and_specifications.htm

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

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:
http://www.gdal.org/ogr__core_8h.html#a787194bea637faf12d61643124a7c9fc

--strk;