[Maria-developers] MATCH returns -1
Hello Sergei, This script: DROP TABLE IF EXISTS t1; CREATE TABLE t1 (a VARCHAR(30), b DOUBLE); INSERT INTO t1 values('aaaa bbbb cccc dddd', MATCH (a) AGAINST('bbbb' IN BOOLEAN MODE)); SELECT * FROM t1; returns: +---------------------+------+ | a | b | +---------------------+------+ | aaaa bbbb cccc dddd | -1 | +---------------------+------+ What does this -1 mean? Is this a bug? Thanks!
When I debugged the code I found this if (ft_handler == NULL) DBUG_RETURN(-1.0); And that is why It returns -1 I guess ft_handler is null, it is set by init_search but I am not getting which function is calling init_search Regards sachin On Wed, Jun 8, 2016 at 12:27 PM, Alexander Barkov <bar@mariadb.org> wrote:
Hello Sergei,
This script:
DROP TABLE IF EXISTS t1; CREATE TABLE t1 (a VARCHAR(30), b DOUBLE); INSERT INTO t1 values('aaaa bbbb cccc dddd', MATCH (a) AGAINST('bbbb' IN BOOLEAN MODE)); SELECT * FROM t1;
returns:
+---------------------+------+ | a | b | +---------------------+------+ | aaaa bbbb cccc dddd | -1 | +---------------------+------+
What does this -1 mean?
Is this a bug?
Thanks!
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Hi, Alexander! On Jun 08, Alexander Barkov wrote:
This script:
DROP TABLE IF EXISTS t1; CREATE TABLE t1 (a VARCHAR(30), b DOUBLE); INSERT INTO t1 values('aaaa bbbb cccc dddd', MATCH (a) AGAINST('bbbb' IN BOOLEAN MODE)); SELECT * FROM t1;
returns:
+---------------------+------+ | a | b | +---------------------+------+ | aaaa bbbb cccc dddd | -1 | +---------------------+------+
What does this -1 mean?
double Item_func_match::val_real() { DBUG_ENTER("Item_func_match::val"); if (ft_handler == NULL) DBUG_RETURN(-1.0);
Is this a bug?
I believe so! Regards, Sergei
Hello Sergei How can we solve this bug? Regards sachin On Wed, Jun 8, 2016 at 1:28 PM, Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Alexander!
On Jun 08, Alexander Barkov wrote:
This script:
DROP TABLE IF EXISTS t1; CREATE TABLE t1 (a VARCHAR(30), b DOUBLE); INSERT INTO t1 values('aaaa bbbb cccc dddd', MATCH (a) AGAINST('bbbb' IN
BOOLEAN MODE));
SELECT * FROM t1;
returns:
+---------------------+------+ | a | b | +---------------------+------+ | aaaa bbbb cccc dddd | -1 | +---------------------+------+
What does this -1 mean?
double Item_func_match::val_real() { DBUG_ENTER("Item_func_match::val"); if (ft_handler == NULL) DBUG_RETURN(-1.0);
Is this a bug?
I believe so!
Regards, Sergei
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Hi Sergei, On 06/08/2016 11:58 AM, Sergei Golubchik wrote:
Hi, Alexander!
On Jun 08, Alexander Barkov wrote:
This script:
DROP TABLE IF EXISTS t1; CREATE TABLE t1 (a VARCHAR(30), b DOUBLE); INSERT INTO t1 values('aaaa bbbb cccc dddd', MATCH (a) AGAINST('bbbb' IN BOOLEAN MODE)); SELECT * FROM t1;
returns:
+---------------------+------+ | a | b | +---------------------+------+ | aaaa bbbb cccc dddd | -1 | +---------------------+------+
What does this -1 mean?
double Item_func_match::val_real() { DBUG_ENTER("Item_func_match::val"); if (ft_handler == NULL) DBUG_RETURN(-1.0);
Is this a bug?
I believe so!
What should happen instead? Should it return 1 instead of -1? Or, should we disallow MATCH in this context?
Regards, Sergei
Hi, Alexander! On Jun 08, Alexander Barkov wrote:
double Item_func_match::val_real() { DBUG_ENTER("Item_func_match::val"); if (ft_handler == NULL) DBUG_RETURN(-1.0);
Is this a bug? I believe so!
What should happen instead? Should it return 1 instead of -1? Or, should we disallow MATCH in this context?
I think (don't remember exactly) that ft_handler should never be NULL when val_real() is called. It's NULL because the initialization code hasn't been called. This shoud be fixed. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
participants (3)
-
Alexander Barkov -
Sachin Setia -
Sergei Golubchik