Using the term "signals" was a bit confusing to me. But this looks like a SQL linting tool?
Seems like it's doing something similar to sqlfluff lint, even supporting the same dialects.
Also the GitHub link in the docs section leads to a 404.
whoami4041•8m ago
Great question! sqlfluff catches real things like "= NULL" bugs, implicit cross joins, unused CTEs, and SELECT *. It's a genuinely useful code quality tool. The dialect coverage of sqlfluff is also extensive. Lexega's dialect implementations focus on depth over breadth.
Lexega is asking a different question though. sqlfluff asks "is this SQL well-written?", while Lexega asks "is this SQL dangerous?". It parses into a full AST and emits signals (categorized AST components) that can be matched against YAML rules to block PRs or execution in agent runtime mode. DELETE without WHERE, GRANT to PUBLIC, PII exposure without masking, DDL that drops tables in production pipelines. The output isn't "fix your style", it's "this query violates an organizational risk policy and shouldn't be allowed to hit production".
Think code quality vs. risk analysis. Both useful, different jobs.
Good call on the GitHub link - I need to fix that.
beart•23m ago
Seems like it's doing something similar to sqlfluff lint, even supporting the same dialects.
Also the GitHub link in the docs section leads to a 404.
whoami4041•8m ago
Lexega is asking a different question though. sqlfluff asks "is this SQL well-written?", while Lexega asks "is this SQL dangerous?". It parses into a full AST and emits signals (categorized AST components) that can be matched against YAML rules to block PRs or execution in agent runtime mode. DELETE without WHERE, GRANT to PUBLIC, PII exposure without masking, DDL that drops tables in production pipelines. The output isn't "fix your style", it's "this query violates an organizational risk policy and shouldn't be allowed to hit production".
Think code quality vs. risk analysis. Both useful, different jobs.
Good call on the GitHub link - I need to fix that.