Adding support for SingleStore

[carlsverre]

Hello! I am an engineer at SingleStore (https://www.singlestore.com/). We build a 99% MySQL compatible database which supports scale out workloads. Unfortunately, we detected a small incompatability between one of our information_schema tables and the corresponding table in MySQL. The specific table is called "parameters". In SingleStore we return a trailing NULL for certain types which causes this connector to fail when it later looks up a type called "int NULL" for example.

I hope this patch can be a starting point to making the parser more robust. I am happy to do more testing if required as a blanket "NULL" replace might not be completely safe here. Possibly if NULL Is the only thing left, then we should keep it, but if it's trailing something else then we should remove it. Would love some suggestions.

Thanks for your time and consideration!

[bgrainger]

Should a test for INT NULL (or INT(11) NULL; what does SingleStore use?) be added here?

[carlsverre]

I added a generic NULL test rather than specific ones (see line 209 below)

SingleStore will return INT(11) NULL so the third test on line 186 will test it.

[bgrainger]

https://www.singlestore.com/free-software/ ends in a form to fill out; is there a simple way to spin up a local instance for testing with Docker?

No, looks like even the Docker Hub image requires a license key via an environment variable: https://hub.docker.com/r/memsql/cluster-in-a-box

May I suggest you make it easier to test SingleStore with just docker run -e ROOT_PASSWORD=pass -p 3306:3306 -p 8080:8080 memsql/cluster-in-a-box (and have it default to using a trial license if one isn't provided).

[carlsverre]

That's good feedback and it's something we have gone back and forth about over the years. For now if you don't want to create an account I will happily send you a free edition license which will allow the tests to run no problem. If you want to add it to the repo just use a secret variable for the pipelines if that is ok. You can email me for the license if needed: carl at singlestore dot com.

[carlsverre]

Looks like this PR doesn't handle all the possible differences between SingleStore's DTD_IDENTIFIER and MySQL's. We are investigating and will propose a more suitable fix. Is there a test which runs this code against MySQL directly for conformence testing?

[carlsverre]

@tavanesov-ua will take this diff over, he is writing a much more robust version of the parser. We should probably also add tests which run directly against SingleStore using our docker container as additional verification. Might do that in a followup PR though. Should have an update here by this time tomorrow.

[bgrainger]

Is there a test which runs this code against MySQL directly for conformence testing?

It's run indirectly via StoredProcedureTests.

IIRC there's no specific test that tests only SQL parsing for stored procedures against a real MySQL server.

[tavanesov-ua]

MySQL documentation is not strict about DTD_IDENTIFIER field. It says
The DTD_IDENTIFIER value contains the type name and possibly other information such as the precision or length.

which basically means it can contain additional elements which we add in SingleStore, because we support default values and not null specifier for the function parameters (similarly to the table columns).
The idea is to skip unknown elements and parse only known types. For unknown types, we assume the first element up to space is the type as all MySQL multipart names are already handled here and SingleStore doesn't have multipart data type names.

[carlsverre]

Nice job @tavanesov-ua - this looks solid to me. @bgrainger what do you think?

[bgrainger]

Thanks--I missed that this commit had been rewritten. The new approach looks much more robust (and thanks for the extra tests). I'm concerned about all the extra allocations, but can push some changes to improve that.

[carlsverre]

Thanks @bgrainger !

[bgrainger]

Added in 1.3.7.

[tavanesov-ua]

@bgrainger thank you!