[OpenSIPS-Users] MySQL Type: FIELD_TYPE_NEWDECIMAL (246) uses DB_INT result type but should use float

[Brett Nemeroff]

Liviu,
In my opinion, way too much work for almost no value. I wouldn’t worry
about it. I think the 8 digits of precision is ok for now really. Certainly
meets my needs.

As a middle ground, instead of extending db_val_t, what if you used the
cues from the DB driver to enforce the digits of precision while casting to
a STRING. The problem with how you do it now is that you assume the
precision which might actually be wrong.

-Brett

On Wed, Mar 11, 2020 at 10:40 AM Liviu Chircu <liviu at opensips.org> wrote:

> On 10.03.2020 20:55, Brett Nemeroff wrote:
> > Can you inspect the DB type to derive a precision for the STRING
> > format? Then maybe default to 8 if you can't derive it?
>
> We probably could, but looking at db/db_val.h +75, you can see that the
> generic db_val_t type has no support for storing the precision.  So we'd
> have to:
>
> * extend this struct so it includes "precision digits" for floating
> point types.  Hopefully with 0 side-effects!
> * add some handy get/set macros for the above
> * for the MySQL driver: inspect the column properties (it has to be
> possible) and extract/store the decimal digits into the result
> * for other SQL drivers: feature not implemented for now?!
> * in avpops, make use of the db_val_t precision digits and finally use
> them to properly format the output data
>
> So this seems like too much of a hassle for a minor (if any)
> improvement, at least in my opinion.  There are other tasks far more
> important to be done for 3.1 instead of this little quirk.
>
> PS: Yesterday, I already pushed the 8-digits patch upstream anyway :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200311/0bff0eda/attachment.html>