Skip to content

Fix incorrect default param types for mssql, oracle, and sqlite#87

Open
rathboma wants to merge 3 commits intomainfrom
fix/param-types-mssql-oracle-sqlite
Open

Fix incorrect default param types for mssql, oracle, and sqlite#87
rathboma wants to merge 3 commits intomainfrom
fix/param-types-mssql-oracle-sqlite

Conversation

@rathboma
Copy link
Contributor

Summary

Fixes #55 — three bugs in defaultParamTypesFor():

  • mssql: named prefix was ':' but T-SQL uses @name syntax → changed to '@'
  • oracle: fell through to positional: true but OCI/python-oracledb/node-oracledb use :name and :N → added named: [':'], numbered: [':']
  • sqlite: was missing $name syntax → added '$' to named prefixes (all five native SQLite forms now covered)

Test plan

  • Updated broken mssql tests in tokenizer, parser, and identifier suites to use @ prefix
  • Updated CREATE FUNCTION identifier test to reflect correct @-prefixed parameter detection
  • Updated double-colon regression test to assert :: doesn't produce : params (preserving original intent)
  • Added oracle :name named-param tests (tokenizer + identifier)
  • Added oracle :N numbered-param test (identifier)
  • Added sqlite $name tests (tokenizer + identifier)
  • All 488 tests pass (npm test)

🤖 Generated with Claude Code

rathboma and others added 3 commits February 26, 2026 12:34
- mssql: change named prefix from ':' to '@' (T-SQL uses @name, not :name)
- oracle: add named [':'] and numbered [':'] (OCI/node-oracledb use :name and :N)
- sqlite: add '$' to named prefixes ($name is natively supported by SQLite)

Update all affected tests to match the corrected syntax.

Fixes #55

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
T-SQL supports both @name (native) and :name (common in ORMs/drivers).
Add ':' to mssql named prefixes and add tests for colon-style params.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes incorrect default parameter type configurations for three SQL dialects (MSSQL, Oracle, and SQLite) to align with their actual parameter syntax conventions.

Changes:

  • MSSQL: Changed primary parameter prefix from : to @ (T-SQL standard), while maintaining : for backward compatibility
  • Oracle: Added explicit support for :name named parameters and :N numbered parameters (previously fell through to generic positional-only mode)
  • SQLite: Added support for $name parameter syntax (completing support for all 5 SQLite parameter forms)

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file
File Description
src/parser.ts Updated defaultParamTypesFor() to return correct parameter prefixes for mssql (['@', ':']), oracle (: for both named and numbered), and sqlite (added $ to named prefixes)
test/tokenizer/index.spec.ts Updated mssql tests to use @ prefix, removed mssql from numbered parameter test, added new tests for mssql @ parameters, oracle :name parameters, and sqlite $name parameters
test/parser/single-statements.spec.ts Updated mssql parameter extraction tests to use @foo and @bar instead of :foo and :bar
test/index.spec.ts Modified double-colon regression test to verify :: doesn't produce colon-prefixed parameters (while allowing valid @ parameters to be detected)
test/identifier/single-statement.spec.ts Updated mssql tests to use @ prefix, corrected CREATE_FUNCTION test to expect detected @ parameters, added new tests for mssql colon-prefixed parameters (backward compatibility), oracle named/numbered parameters, and sqlite $name parameters

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

type: 'CREATE_FUNCTION',
executionType: 'MODIFICATION',
parameters: [],
parameters: ['@DATE', '@ISOweek'],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a bug to me, since they're not parameters that the user would need to fill in. We can at least detect variables within a function/body by checking if the preceding token is DECLARE, though I'm a bit of a loss for dealing with function parameters.

result.forEach((res) => {
expect(res.parameters.length).to.equal(0);
// :: cast syntax should not produce colon-prefixed parameters
expect(res.parameters.every((param) => !param.startsWith(':'))).to.equal(true);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feels like can rework the this test to then only do identify('SET @g = geometry::STGeomFromText('POLYGON((0 0, 2 0, 2 2, 0 2, 0 0))', 0);') if just checking that cast isn't parsed to a parameter.

However, similar to above, would be good to think about how we should handle these parameters here.

@Mariajose-prog
Copy link

Done

21 similar comments
@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

28 similar comments
@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

@Mariajose-prog
Copy link

Done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

FEAT: Support a variety of parameter types per syntax type

5 participants