Does it mean that there is no sense to make feature requests (or, for Oracle engineers, to process them and keep status in sync with reality)? No, it does not, IMHO. This is still one of few ways for a community user or even a customer to influence the future of MySQL. Even if Oracle will not start to act immediately in any obvious way based on your feature request, it will still be documented, reviewed by Oracle engineers, other community users and maybe even developers from other forks. Entire world will know what is missing (and accepted as missing by vendor, if feature request is "Verified"). Then, based on its status changes, entire world will know if anybody cares enough...
So, let me continue my previous post about oldest but still formally "Verified" bugs with a list of 12 oldest and still "Verified" feature requests:
- Bug #400 is the oldest and it remains "Verified" since good old days when Monty himself replied to MySQL feature requests. It's about backslash (\) usage as escape character before single and double quotes. I do not have any opinion about it, but still it's the oldest still "Verified" feature request.
- Bug #765 - "mysqlimport should read from stdin standard input". Maybe, it's a kind of a "Unix way" to have some option to do so...
- Bug #1118 - "Allow multiple concurrent locks with GET_LOCK()". This one from Dean Ellis I'd like to see implemented years ago. And it was implemented recently by former famous MySQL developer, Konstantin Osipov, who had made a BSD-licensed patch available here. Feature request is still just "Verified", bit this is how it may work: even if not Oracle, somebody can pick up useful feature request and implement it.
- Bug #1154 - "cannot rename temporary table". I really wonder why not to make RENAME working the same way as ALTER TABLE ... RENAME in this case. Nobody wants to touch old code and test cases maybe...
- Bug #1207 - this is a request for function to count the number of substring occurrences in a string, like PHP's substr_count(). Workarounds are more or less obvious, so this feature request may hang around not implemented for 10 more years easily...
- Bug #1214 - "Unique row identifier data type for MySQL (like MSSQL uniqueidentifier)". UUID() mostly works for this if MIXED/ROW-based replication is used, but still this concern expressed by James Day remains:
"Decision needed for this bug is if UUID() should be our answer to a unique identifier feature request in 5.1 and later. It's very non-optimal for InnoDB primary key use because it puts the most rapidly changing parts of the time first."
Check the bug report for different workarounds, but ultimate solution is not yet in place it seems. - Bug #1275 - "Multiple uninstall options if upgrade a preexisting install in same directory". This is a Windows-specific feature request and I am not sure what's going on now with new installers. I had never really tried to upgrade in place in real life using .msi or new installer (if maybe to verify some bug report). It's surely better to install every version into its own directory and then play with datadir in my.ini to make upgraded MySQL work with data from previous version.
- Bug #1309 - "EXCEPT statement". One of the early requests to have all kind of relational operations requested by standard in MySQL. Of them we still have only UNION [ALL].
- Bug #1310 - "optionally add queries with lock times to slow_query log". I assumed this is already implemented, but I may be wrong...
- Bug #1327 - "I would like functions/SQL commands in the MySQL API/Language so that a client application can be notified when things happen in the database." Now I am not sure if we need to implement anything for this, but back in 2005 I thought there is something to consider here. Still "Verified" since that time.
- Bug #1341 - "InnoDB ibdata1 never shrinks after data is removed". Still the case. Setting innodb_file_per_table=1 and using separate tablespaces for undo in MySQL 5.6 partially solves the problem (by removing reasons for ibdata1 to grow much). But users still complain, for 10 years already...
- Bug #1343 - "index by date part of datetime field". I've suggested some kind of a workaround there back in 2005.
No comments:
Post a Comment