Sublime Forum

Inheritance for sql syntax variants?

#1

Using sublime version 3.0 build 3143

Trying to create a sql Teradata.sublime-syntax variant and google seems to have failed me on how to “inherit” an existing syntax. I’ve looked at other sql like language packages (ie Hive) but they seem to have rolled their own syntax using .tmLanguage files. So here I am asking the hive mind.

Below is my attempt to inherit to get “CREATE SET TABLE foo.bar” to highlight as a keyword from my syntax as well as “SELECT ‘foo’;” . In reading the docs it appears I can push regex matches to other libraries for evaluation but I think I’m missing something…

So far my syntax highlights my “CREATE SET TABLE” but nothing from the Packages/SQL/SQL.sublime-syntax. So is there no other fix rather than copying the entire builtin SQL.sublime-syntax file and adding my own vendor specific keywords?

%YAML 1.2
---
name: TeradataSql
file_extensions:
  - sql
  - ddl
  - dml
scope: source.sql
contexts:
  main:
    - match: '(?i:\s*\b(create|create set|create multiset(?:\s+or\s+replace)?)\s+(aggregate|conversion|database|domain|function|group|(?:unique\s+)?index|language|operator class|operator|procedure|rule|schema|sequence|table|tablespace|trigger|type|user|view)\s+)(?:(\w+)|''(\w+)''|"(\w+)"|`(\w+)`)'
      scope: meta.create.sql
      captures:
        1: keyword.other.create.sql
        2: keyword.other.sql
        3: entity.name.function.sql
        4: entity.name.function.sql
        5: entity.name.function.sql
        6: entity.name.function.sql
  ansii:
    - match: ""
      push: "Packages/SQL/SQL.sublime-syntax"

This text will be hidden

0 Likes
#2

I see two problems with this:

  • your ansii context is never pushed/included onto the stack
  • if it was, there is nothing to pop the SQL context again

I recommend trying a tool a community member has written for this very purpose

3 Likes
#3

Thanks for the push in the right direction kingkeith! Took me a while to determine how to get the !prepend function to work since the prexisting SQL.sublime-syntax would clobber my specific example if it was just pushed to the end. Now to get cranking on a few more keywords.

Below is the updated .sublime-syntax.yaml-macros that works. I really gotta brush up on my understanding of regex…

%YAML 1.2
%TAG ! tag:yaml-macros:YAMLMacros.lib.extend:
---
!extend
_base: SQL.sublime-syntax
name: TeradataSql
file_extensions:
  - tsql
scope: source.sql

contexts: !merge
  main: !prepend
    - include: teradata
  teradata: 
    - match: '(?i:\s*\b(create|create set|create multiset(?:\s+or\s+replace)?)\s+(aggregate|conversion|database|domain|function|group|(?:unique\s+)?index|language|operator class|operator|procedure|rule|schema|sequence|table|tablespace|trigger|type|user|view)\s+)(?:(\w+)|''(\w+)''|"(\w+)"|`(\w+)`)'
      scope: meta.create.sql
      captures:
        1: keyword.other.create.sql
        2: keyword.other.sql
        3: entity.name.function.sql
        4: entity.name.function.sql
        5: entity.name.function.sql
        6: entity.name.function.sql
1 Like
#4

My hope is that over the next few months we (as a community) can work on creating variants of the SQL syntax to target the different engines, since there are some syntax elements that make it impossible to target all syntax in a single… syntax.

Ideally I’d love to get a variant for:

  • MySQL
  • PostgreSQL
  • SQLite
  • MSSQL
  • Oracle

Then we’d change the syntax in the default packages to include scope:source.sql and allow some way for the user to decide which variant should be the “default” for that syntax.

3 Likes
#5

Are we talking about adding default packages?

I have an Oracle package I’ve been using awhile, and it might be a useful starting point for any new high-qualify SQL syntax. The only caveat is that it relies heavily on my macro system – the .sublime-syntax files are around twice the size of the source with macros. SQL syntax is generally awful, and a faithful implementation of Oracle’s syntax may be simply impractical without macros. I can’t say to what extent this may also be true of other common SQL dialects.

One possibility would be integrating a macro system into core. This is certainly not a trivial proposition! I think that the macros add real expressive power* to the syntax engine, or else I wouldn’t have created them to begin with, but obviously I’m not unbiased here. Other possible applications within the core packages might include UNIX shell dialects (bash, zsh, fish, etc) and JavaScript extensions like JSX (see this 103-line implementation).

* Practical expressive power; obviously not from a CS standpoint.

0 Likes