[SQL] Add support for build-in MariaDB/MySQL/PostgreSQL functions

[anticultist]

This PR adds support for the build-in MariaDB/MySQL functions listed in:
https://mariadb.com/kb/en/built-in-functions/

Due to possible conflicts, the following functions are not included: CHAR, DATE, DEFAULT, DISTINCT, IF, INSERT, POINT, POLYGON, SYSDATE, TIME, TIMESTAMP, TRUNCATE, VALUE, VALUES

Those functions were already included: AVG, CONVERT, COUNT, CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, CURRENT_USER, LOWER, MAX, MIN, SESSION_USER, SUBSTRING, SUM, SYSTEM_USER, TRIM, UPPER

[deathaxe]

Now that we have inheritance, I wonder whether we should create dedicated syntaxes for each server type instead of flooding the general/basic syntax.

[anticultist]

I have some questions about that: First of all, is there any documentation or example out there which describes/shows the inheritance feature? The other one, is it a new feature for ST4 or will it be back-ported to SL3 some day? In more general is this a repository for ST3, ST4 or both?!

Furthermore I have a more specific question about the implication of that strategy in that case: When a python string starts with SELECT/INSERT/UPDATE the string inside will be treated as SQL code. So how we can specify the specific SQL dialect for that sting? And the more complicated scenario is that for a single python file there are strings for more than one SQL dialect. Is there any good way to handle this in the current version of inheritance right now?

[deathaxe]

is there any documentation or example

1. Makefile Shell.sublime-syntax is an inherit syntax from Bash.sublime-syntax
2. HTML.sublime-syntax extends HTML (Plain).sublime-syntax
3. The TSX, JSX syntaxes are inherit from JavaScript.

Looking for extends may reveal more.

An internal documentation is available, yes. Not sure whether I am allowed to post links here. It may be found on ST's Discord server.

will it be back-ported to SL3 some day?

ST 3 won't receive any updates anymore, except for fixes required to keep it running due to OS changes.

Syntaxes in this repo are always developed against the latest builts of ST, only.

So how we can specify the specific SQL dialect for that sting

The first step was to create proper main scopes such as source.sql.mysql, source.sql.mariadb, etc. so all the dialects may be identified uniquely.

As there's no syntactical way for python to know about the used sql dialect it can only embed a single one at a time.

Inherited Python (MariaDB) syntaxes could be created for each dialect. Selecting the correct variant may need manual interaction though.

a single python file there are strings for more than one SQL dialect

How would you distinguish them per syntax? You'd need some kind of tag which tells the lexer, which dialect to use.

---

There have been a couple discussions about adding support for all sorts of databases into that syntax, which has always been judged sub optimal, because the feedback about whether the correctly highlighted command is valid for the engine of choice is not precise then. Sometimes syntax is even different.

[michaelblyons]

First of all, is there any documentation or example out there which describes/shows the inheritance feature?

Yes, but documentation is not officially released. Check DeathAxe's suggestions above.

The other one, is it a new feature for ST4 or will it be back-ported to [ST3] some day?

I cannot speak for SHQ, but I believe the answer is "No."

In more general is this a repository for ST3, ST4 or both?!

Ongoing changes are really ST4. There's a point where it shifted.

So how we can specify the specific SQL dialect for that [string]?

Right now, Python embeds source.sql. If the SQL inheritance was laid out like so:

• source.sql.ansi
  • source.sql.tsql
  • source.sql.mysql
  • …

then you could make a single stand-alone file that called its scope source.sql, but immediately deferred to a different SQL variant under the hood. We sort of have this now with "Shell-Unix-Generic" (source.shell) delegating to Bash (source.shell.bash). I've actually been doing this for SQL myself for a year or more. Somewhat frustratingly, that means every time someone merges a SQL PR here (like this one) I have to rebase some merge conflicts.

And the more complicated scenario is that for a single python file there are strings for more than one SQL dialect. Is there any good way to handle this in the current version of inheritance right now?

There's not really a good way. You could hypothetically override or inherit a modified Python syntax definition that understood hints in your code to trigger different SQL variants, but the code itself would have to indicate that this UPDATE is MySQL and that UPDATE is Postgres. One such example would be like this:

if dbms == DBMS.MYSQL:
    sql = '''-- MySQL
        SELECT  `foo`.id
        FROM    `foo`
    '''
elif dbms == DBMS.TSQL:
    sql = '''-- TSQL
        SELECT  [foo].id
        FROM    [foo]
    '''

But this would obviously be a convention in only your code.

[anticultist]

Thanks for the answers. So I moved the MySQL functions to a dedicated file to start new syntax definition files for each dialect as suggested. Because it looks odd to just have one SQL dialect, I decided to add a second one for PostgreSQL, which now also just has the built-in functions.

By the way, I was not sure how I should name the SQL dialect: MySQL, MariaDB, MySQL/MariaDB... I decided to go with MySQL because it is the original one and may be more known than MariaDB. I believe that people knowing MariaDB also know MySQL but not always vise versa. So if they have to select a specific SQL dialect, it should be easier for them if that dialect is called MySQL. But of cause if those dialects drift more apart in the future, we can decide to introduce MariaDB as well. I hope that is fine. If not please comment on this.

[michaelblyons]

Small style note: Comments in this repo typically use # now, rather than the comment: key.

[anticultist]

Funny, before I saw the "comment"-key version of comments in SQL.sublime-syntax file I would probably have used the "#"-comments. I thought it is the way how comments are used here. But now I know that it is the former way to make comments. So I changed my and the older comments into the "new" style comments. Thereby no one should be misled to use that comment style.

[michaelblyons]

So how we can specify the specific SQL dialect for that [string]?

Right now, Python embeds source.sql. If the SQL inheritance was laid out like so:

• source.sql.ansi

  • source.sql.tsql
  • source.sql.mysql
  • …

then you could make a single stand-alone file that called its scope source.sql, but immediately deferred to a different SQL variant under the hood. We sort of have this now with "Shell-Unix-Generic" (source.shell) delegating to Bash (source.shell.bash).

@keith-hall has started this in #3046