[MDEV-13239] Parameters are ignored if OPTION_LIST contains space(s), MYSQL type table(CONNECT engine) Created: 2017-07-04  Updated: 2017-07-14  Resolved: 2017-07-04

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - Connect
Affects Version/s: 10.1, 10.2, 10.3
Fix Version/s: 10.1.26, 10.0.32, 10.2.8

Type: Bug Priority: Major
Reporter: Alice Sherepa Assignee: Olivier Bertrand
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu 16.04



 Description   

When OPTION_LIST contains spaces, then results are incorrect. Supposedly it use parameters, that were used on connecting to the current client.

In the test case below table c1 have to connect on port 3322, but instead it uses current port 3311. (in my case table c1 connects to the same server and reads information about itself )

select @@port;
+--------+
| @@port |
+--------+
|   3311 |
+--------+
 
CREATE TABLE c1 ENGINE=CONNECT TABLE_TYPE=MYSQL 
DBNAME=information_schema OPTION_LIST='host=127.0.0.1, port=3322,user=root', tabname=tables;
Query OK, 0 rows affected (0.06 sec)
 
SELECT * FROM c1 WHERE TABLE_NAME='c1'\G
 
1 row in set (0.00 sec)
*************************** 1. row ***************************
  TABLE_CATALOG: def
   TABLE_SCHEMA: test
     TABLE_NAME: c1
     TABLE_TYPE: BASE TABLE
         ENGINE: CONNECT
        VERSION: 10
     ROW_FORMAT: Dynamic
     TABLE_ROWS: 10
 AVG_ROW_LENGTH: 0
    DATA_LENGTH: 0
MAX_DATA_LENGTH: 0
   INDEX_LENGTH: 0
      DATA_FREE: 0
 AUTO_INCREMENT: NULL
    CREATE_TIME: NULL
    UPDATE_TIME: NULL
     CHECK_TIME: NULL
TABLE_COLLATION: latin1_swedish_ci
       CHECKSUM: NULL
 CREATE_OPTIONS: `TABLE_TYPE`='MYSQL' `TABNAME`='tables' `DBNAME`='information_schema' `OPTION_LIST`='host=127.0.0.1, port=3322,user=root'
  TABLE_COMMENT: 
1 row in set (0.00 sec)



 Comments   
Comment by Olivier Bertrand [ 2017-07-04 ]

The CONNECT MariaDB documentation in:
https://mariadb.com/kb/en/mariadb/creating-and-dropping-connect-tables/
Says:
Be aware that no blanks should be inserted before or after the '=' and ',' characters.

Comment by Elena Stepanova [ 2017-07-04 ]

bertrandop, please reconsider.

The other day we spent about two hours between two of us trying to figure out why a seemingly straightforward CREATE TABLE did something totally different from what one would expect; and while I might be blamed for not reading documentation, Alice did read it at some point, probably much more than an average user would.

Even for people who read documentation beforehand, which are rare, it's impossible to remember every single tiny detail like that. If the statement failed, then yes, it would be natural to dig into documentation trying to figure out what we did wrong.

But the statement didn't fail, it didn't throw warnings, it would just point at a wrong server, which is extremely dangerous in real use. We only noticed it because of weird side-effects that we observed; if it weren't the case, we would be operating on a wrong server and wrong tables.

It's okay not to support blank spaces (even although weird), but then there must be a syntax error of some sort.

Comment by Olivier Bertrand [ 2017-07-04 ]

When parsing, it is often as easy to accept then to make a precise diagnostic.

Therefore, I preferred to release the restriction about blanks.

Generated at Thu Feb 08 08:04:00 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.