If the target fields in the database are of type CHAR (not VARCHAR), you can make DBI do so by:
$dbh->{ChopBlanks} = 1;
Some DBD's do extend this behavior to VARCHAR fields (when the database it too stupid to do so itself, as the ANSI standard tells it to) or when VARCHAR effectively is a CHAR internally (because the database doesn't support VARCHAR).
YMMV
Enjoy, Have FUN! H.Merijn
| [reply]
[d/l]
[select] |
| [reply]
[d/l] |
Try to read (and understand) this sheet from one of my presentations. All Orange fields do NOT meet my expectations or the standard.
The page is old, but most of those still hold true.
Enjoy, Have FUN! H.Merijn
| [reply] |
Well, one thing I found is that all FLOAT (and probably DOUBLE) values are returned as string (for example "0.00" for a column defined as FLOAT(7,2)).
Using DBD::MySQL 4.0.18 (should that matter) with default connection options. | [reply] |
one thing I found is that all FLOAT (and probably DOUBLE) values are returned as string
That does make a certain amount of sense.
If you converted floats to their binary numeric representation, then you could introduce typical floating point representation errors. If you are going to do math with them in your perl code, then that will happen anyway and you'd have to deal with it.
But if you are only going to display them, or store them into another table somewhere, then returning them as strings means that you don't have to deal with those errors.
Whether that is the reasoning behind it I cannot say, but it could be.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
I would expect this to be the case for Fixed-Point values (DECIMAL and NUMERIC types), but not for FLOAT and DOUBLE, which already suffer from floating point representation errors because, well, that's what they are (even inside MySQL).
| [reply] |
