View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016584 | mantisbt | filters | public | 2013-11-07 05:04 | 2014-12-08 00:34 |
| Reporter | kensonman | Assigned To | dregad | ||
| Priority | urgent | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | Chrome | OS | Ubuntu Linux + PostgreSQL | ||
| Product Version | 1.2.15 | ||||
| Target Version | 1.3.0-beta.1 | Fixed in Version | 1.3.0-beta.1 | ||
| Summary | 0016584: Error when query bug by custom-field (date) in postgresql | ||||
| Description | The error message are prompted. Error message: | ||||
| Steps To Reproduce |
| ||||
| Additional Information | I had fixed those issue by below modification: @@ -1890,19 +1890,19 @@ function filter_get_bug_rows( &$p_page_number, &$p_per_page, &$p_page_count, &$p
| ||||
| Tags | No tags attached. | ||||
|
I'm trying to fix this issue according to SQL92, so it should be work on both postgresql and mysql. |
|
|
The only problem is that while the SQL CAST() function is indeed SQL standard and does exist in the various RDBMS, the available types differ. Using your example, MySQL does not allow 'INT' [1]; I think the most portable type to use would be DECIMAL, however that requires MySQL 5.08 or later (which conflicts with our current minimum requirements). [1] http://dev.mysql.com/doc/refman/5.0/en/cast-functions.html#function_cast |
|
|
According to the below linkage[1], the INT should be supported in MySQL 4.1. For better backward compatibility, may be NUMERIC is the good choice. [1]http://dev.mysql.com/doc/refman/4.1/en/integer-types.html |
|
|
As per my link, neither INT nor NUMERIC are supported by the CAST function (EDIT: in MySQL). You can used SIGNED [INTEGER] or UNSIGNED [INTEGER], but that in turn is not accepted by other RDBMS. |
|
|
MantisBT: master d46001bd 2013-11-08 03:26 Details Diff |
Fix error with PostgreSQL when filtering on date custom field As PostreSQL tries to add 0 to a string, it throws an error as it tries to operate on different data types. I can only guess that the +0 was a hack to convert type from string to integer on MySQL. Implementing solution proposed by user kensonman, using standard SQL functions CAST, COALESCE and NULLIF to achieve a clean and portable conversion to numeric (this assumes that the data stored in the custom_fields_string table 'value' column is indeed numeric; if not we would get other errors or warnings) Note: this requires bumping MySQL minimum requirement to 5.08, since DECIMAL type used in CAST was only added in that release. Fixes 0016584 |
Affected Issues 0016584 |
|
| mod - core/filter_api.php | Diff File | ||
| mod - docbook/Admin_Guide/en-US/Installation.xml | Diff File | ||