SQL Server tsql base abstract class introduction

[vitorelourenco]

This is mainly so we can discuss the decisions I had to make and how do we want to go about it.
Some major ones are the wrapping of the main select block (not fully done atm but we can talk about the approach)
groupByClause instead of only orderByClause
Support for not needing regexp
The support for not having 'LIMIT' available in the dialect
Having booleans as numbers or expressions eg 1=1

The changes to malloy_query.ts are pretty significant.

This PR is expected to fail all sorts of tests but I feel like this is the point to start ping-ponging ideas.

Edit (may 16th, 2025) : I'm tyring to ditch the wrapping approach. Too many problems wit aliases in the internal query being unavailable to the outer query, specially FROM aliases.
I also had to create a tally/numbers table cause sqlserver can't generate sequences on the fly without a CTE in a simple manner

Edit (may 26th, 2025) : There are still things to sort out, its not ready for usage but I would like to make more incremental changes, possibly making tsql abstract as a base and having sqlserver, azure sql and synapse extending

[mtoy-googly-moogly]

We are having an internal discussion about the copyright block. I HOPE our policy about this is about to be

1. Documented
2. A much smaller wall of text.

TODO Check in again with me before this merges.

[mtoy-googly-moogly]

Something like

export type LimitingClause = 'limit' | 'top';


limitClause: LimitClause = 'limit';

?

[mtoy-googly-moogly]

There are regular expressions in Malloy expressions, but no databases "support" regular expressions as a data type. A regular expression is just a string which has special quoting rules and which therefore acts differently with the ~ operator. I don't think you need to mark them "not supported". If you can implement sqlRegexpMatch, which I think you can, then that is all the "support" needed.

[mtoy-googly-moogly]

I think you get to name it. If a second dialect comes along and you picked a wrong name, we'll just change it then.

[mtoy-googly-moogly]

I think this is a place where @christopherswenson should comment since he is the architect of the standard function library

[mtoy-googly-moogly]

In Malloy source, writing a filter expression or a string match

endsInPercent is strVal ~ '%\\%'
endInPersent is strVal ~ f'%\%'

when the LIKE expression is written, it is assumed that EITHER backslash is the correct escape character or that the dialect as the ESCAPE syntax for the LIKE statement. So really, to make this abundantly clear, this should probably have followed the pattern ...

export type LikeEscapeStyle = 'escape' | 'backslash';


likeEscape: LikeEscapeStyle = 'backslash';

[mtoy-googly-moogly]

This is another place where I'd like @christopherswenson to weigh in

[mtoy-googly-moogly]

Yeah this seems fine

[mtoy-googly-moogly]

so in other "booleanAsNumber" dialects, there are symbols "true" and "false" which evaluate to "1" and "0".

if that isn't the case for tsql then probably there should be a dialect function which returns the true and false values

case 'true':
  return this.parent.dialect.booleanValue(true);
case 'false':
  return this.parent.dialect.booleanValue(false);

And everything except tsql uses

   booleanValue(v: boolean) { return v ? 'true' : 'false' }

[mtoy-googly-moogly]

this should go away and be replaced by the dialect function i mentioned

[vitorelourenco]

Was 1-0 instead of 1=0 intentional?

[vitorelourenco]

fixing a typo