Support for T-SQL

[stackmystack]

Hello Derek,

I would like to add support for Microsoft's T-SQL if possible.

This is a sketch of what it would look like.

I am not happy with the PR's state at all, but I thought I'd share what I have as of now, and collect feedback. I will re-write once, and if, support for T-SQL is accepted, and we agree on how to organise things; I am not proficient with all of the dialects of SQL so I may be implementing things in a stupid way.

The most important thing I would like to see, is recognising @variable_name from T-SQL as an identifier instead of having it in tsql_parameter as I do right now.

This PR is motivated by a real-world use case, which I can include in the test suite once I figure out how to make it work :) (node-gyp on my mac is not happy):

IF OBJECT_ID (N'dbo.LEVENSHTEIN_DISTANCE', N'FN') IS NOT NULL
    DROP FUNCTION dbo.LEVENSHTEIN_DISTANCE;
GO
CREATE FUNCTION dbo.LEVENSHTEIN_DISTANCE(@s nvarchar(4000), @t nvarchar(4000))
RETURNS int
AS
BEGIN
  DECLARE @sl int, @tl int, @i int, @j int, @sc nchar, @c int, @c1 int,
    @cv0 nvarchar(4000), @cv1 nvarchar(4000), @cmin int
  SELECT @sl = LEN(@s), @tl = LEN(@t), @cv1 = '', @j = 1, @i = 1, @c = 0
  WHILE @j <= @tl
    SELECT @cv1 = @cv1 + NCHAR(@j), @j = @j + 1
  WHILE @i <= @sl
  BEGIN
    SELECT @sc = SUBSTRING(@s, @i, 1), @c1 = @i, @c = @i, @cv0 = '', @j = 1, @cmin = 4000
    WHILE @j <= @tl
    BEGIN
      SET @c = @c + 1
      SET @c1 = @c1 - CASE WHEN @sc = SUBSTRING(@t, @j, 1) THEN 1 ELSE 0 END
      IF @c > @c1 SET @c = @c1
      SET @c1 = UNICODE(SUBSTRING(@cv1, @j, 1)) + 1
      IF @c > @c1 SET @c = @c1
      IF @c < @cmin SET @cmin = @c
      SELECT @cv0 = @cv0 + NCHAR(@c), @j = @j + 1
    END
    SELECT @cv1 = @cv0, @i = @i + 1
  END
  RETURN @c 
END
GO

[dmfay]

please consider splitting this into two pull requests -- you've got a grab bag of fairly simple, straightforward improvements to t-sql support that are easy enough to evaluate on their own merits, but procedural sql and control flow is a longstanding known gap that has much bigger ramifications for dialect support and performance.

also, needs more tests :)

[dmfay]

this is a lot of "just prec.left it" and it's making me nervous

[dmfay]

I'm pretty surprised we missed this, good catch!

[dmfay]

if my hazy memory of t-sql is anything to go by this might be more an identifier semantically, and making it an option for that would also fit a lot better with what you're doing in function_argument and _qualified_field

[stackmystack]

Yes that's my impression too, I wanted confirmation from your part first.

[vic-t]

@stackmystack I'm curious, have you found a way to introduce bracketed identifiers?

[stackmystack]

please consider splitting this into two pull requests -- you've got a grab bag of fairly simple, straightforward improvements to t-sql support that are easy enough to evaluate on their own merits,

Great, I will do so in a separate PR

but procedural sql and control flow is a longstanding known gap that has much bigger ramifications for dialect support and performance.

I am proposing these changes because I am pretty interested in procedural SQL and control flow. For the time being in T-SQL. I am putting the effort because I need them now. Would you be open to integrating them in main in the near future? In other words, should I fork the lib and not expect those to be accepted any time soon?

also, needs more tests :)

Definitely :)

[DerekStride]

I'm going to close this since it's been split out into separate PRs (#314 #315). Happy to review more if there's additional changes that you'd like to see made.