Bug #27040 Incorrect FTS parser name output
| Submitted: | 12 Mar 2007 5:37 | Modified: | 24 Oct 2007 18:40 |
|---|---|---|---|
| Reporter: | Yoshinori Matsunobu | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: FULLTEXT search | Severity: | S3 (Non-critical) |
| Version: | 5.1.18-BK, 5.1.16 | OS: | Any |
| Assigned to: | Sergey Vojtovich | CPU Architecture: | Any |
| Tags: | Contribution | ||
[29 Mar 2007 6:56]
Valeriy Kravchuk
Thank you for a bug report and contributed patch idea. Verified just as described with code review on latest 5.1.18-BK souces: that part of code is still the same.
[2 Aug 2007 19:00]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/32025 ChangeSet@1.2569, 2007-08-03 03:50:19+05:00, svoj@mysql.com +1 -0 BUG#27040 - Incorrect FTS parser name output When a table uses two (or more) fulltext keys with different fulltext parsers, all fulltext keys (excluding those that use built-in parser) were using first parser that was mentioned in .frm. With this fix fulltext keys use proper (assigned during create table) fulltext parser. This code was contributed by Yoshinori Matsunobu ymatsunobu@mysql.com on 2007-03-12 The copyright was assigned and transferred under the terms of the MySQL Contributor License Agreement.
[22 Oct 2007 17:03]
Bugs System
Pushed into 5.1.23-beta
[24 Oct 2007 18:40]
Paul DuBois
Noted in 5.1.23 changelog. For a table that used different full-text parsers for different FULLTEXT indexes, SHOW CREATE TABLE displayed the first parser name for all of them.
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.041 sec. using MySQL 8.4.7-u6-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.
Description: When using 2 or more FTS parsers for 1 table, SHOW CREATE TABLE reports that all FULLTEXT columns use the same(first) parser. How to repeat: mysql> INSTALL PLUGIN simple_parser SONAME 'xx.so'; mysql> INSTALL PLUGIN simple_parser2 SONAME 'xx2.so'; mysql> CREATE TABLE t (doc CHAR(255), doc2 CHAR(255), FULLTEXT INDEX (doc) WITH PARSER simple_parser, FULLTEXT INDEX (doc2) WITH PARSER simple_parser2); mysql> SHOW CREATE TABLE t\G *************************** 1. row *************************** Table: t Create Table: CREATE TABLE `t` ( `doc` char(255) DEFAULT NULL, `doc2` char(255) DEFAULT NULL, FULLTEXT KEY `doc` (`doc`) /*!50100 WITH PARSER `simple_parser` */ , FULLTEXT KEY `doc2` (`doc2`) /*!50100 WITH PARSER `simple_parser` */ ) ENGINE=MyISAM DEFAULT CHARSET=latin1 1 row in set (0.01 sec) Suggested fix: sql/table.cc open_binary_frm() parser_name.str= next_chunk; parser_name.length= strlen(next_chunk); keyinfo->parser= plugin_lock(&parser_name, MYSQL_FTPARSER_PLUGIN); if (! keyinfo->parser) { my_error(ER_PLUGIN_IS_NOT_LOADED, MYF(0), parser_name.str); my_free(buff, MYF(0)); goto err; } --> parser_name.str= next_chunk; parser_name.length= strlen(next_chunk); next_chunk += parser_name.length + 1; // adding this line keyinfo->parser= plugin_lock(&parser_name, MYSQL_FTPARSER_PLUGIN); if (! keyinfo->parser) { my_error(ER_PLUGIN_IS_NOT_LOADED, MYF(0), parser_name.str); my_free(buff, MYF(0)); goto err; }