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 <li...@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 :) >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users