Bug #39564 | Pad CHAR to full length with spaces does not work | ||
---|---|---|---|
Submitted: | 20 Sep 2008 20:09 | Modified: | 22 Feb 2010 23:37 |
Reporter: | Farid Zidan (Candidate Quality Contributor) | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | Connector / ODBC | Severity: | S2 (Serious) |
Version: | 5.1.5 | OS: | Windows (XP SP3) |
Assigned to: | Assigned Account | CPU Architecture: | Any |
Tags: | Pad CHAR, qc |
[20 Sep 2008 20:09]
Farid Zidan
[20 Oct 2008 19:59]
Jim Winstead
What is the use-case for this functionality? We didn't have any coverage for it in our test suite, which is presumably why it rotted. My inclination would be to just remove the option, without a solid use-case for the functionality.
[20 Oct 2008 21:10]
Farid Zidan
The pad CHAR option is important for cross-dbms apps because MySQL does not by default pad SQL_CHAR/SQL_WCHAR columns with spaces which is the default ANSI behavior ( MS SQL Server, Oracle, DB2, etc ).
[22 Feb 2010 23:37]
Farid Zidan
My SQL Doc for Character data type: [NATIONAL] CHAR[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] A fixed-length string that is always right-padded with spaces to the specified length when stored. M represents the column length in characters. The range of M is 0 to 255. If M is omitted, the length is 1. Can only guess why this is not the default behavior for the driver as otherwise it would be consistent with how character data is stored at the server and with most other databases ODBC drivers and SQL standard
[23 Feb 2010 8:17]
Tonci Grgin
Lawrin, please see to this report.
[2 Dec 2010 10:46]
Tonci Grgin
This bug is still present in 5.1.8 (not in 3.51.27).