SQL system data type synonym name lost and replaced during parsing

Open

#116 opened on Feb 5, 2025 1 comment 5 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 4/5
Estimated time: 3-5 days
Newbie friendliness: 42/100

Issue type: Bug
Clarity: Mostly clear
Activity status: Stale
Tech stack: sql
Domain: compilers

Research direction

Start by reproducing the NATIONAL CHARACTER VARYING and DOUBLE PRECISION examples and inspect DatatypeReference.Name.BaseName alongside SqlDataTypeOption. Determine where parsing replaces or drops the supplied synonym; the work is done when the AST preserves each original data type name while retaining the parser's normalized type information.

Written by the indexing model from the issue text.

Description

ScriptDom version: 161.9142.1
Compatibility level: 150

While trying to implement custom TSQL linter rule which should prevent developers from using non-conventional data type names (synonyms) I've faced an issue: ScriptDom modifies type name during parsing. Which makes detection of synonym usage impossible or hard to implement.

For example:

DECLARE
    @a NATIONAL CHARACTER VARYING (100)
    , @b DOUBLE PRECISION
    , @c INTEGER

Here only "INTEGER" synonym (for INT data type) can be easily detected. Data type name for @a is delivered to DatatypeReference.Name.BaseName partially: it contains CHARACTER word only. Yes, "character" is a synonym as well, but not the one that was actually provided.

Moreover, DOUBLE PRECISION gets lost totally: DatatypeReference.Name.BaseName.Value here comes as Float. It's good to know that the parser knows what is what but actual script contents disappeared after parsing - IMHO this is no good.

I'd expect ScriptDom parser to keep what was provided - a full original data type name no matter if it was a UDT or registered sql-server supplied type synonym. As far as I can understand ScriptDom has SqlDataTypeOption for internal needs and this DatatypeReference's property does contain NVarChar and Float as expected for both of mentioned examples above. Seems like BaseName could keep the original type name.

Dominant language: GAP
Stars: 277
Forks: 43
Avg merge: 6d 17h
Merged PRs (30d): 3

Contributor guide

Open the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.

Similar issues

perf: a definite-value return type (`--> Nil`, `--> True`) sends every call down the full path (~12 µs vs ~1 µs) Open

todo:perf

Difficulty 2/5 1-3 hours Newbie friendliness 84/100

tokuhirom/mutsu#9074 · Opened Sep 22, 2026
StUnhex.number() misformats Long.MIN_VALUE as scientific notation instead of a plain integer Open

Difficulty 2/5 1-3 hours Newbie friendliness 86/100

objectionary/eo#8894 · Opened Sep 22, 2026
PHIE parser rejects the empty object representation Open

Difficulty 2/5 1-3 hours Newbie friendliness 88/100

objectionary/phie#154 · Opened Sep 22, 2026
`EoCodec` stores a `float` as a `double`, so a signaling-NaN float constant comes back with different bits Open

bug

Difficulty 2/5 1-3 hours Newbie friendliness 86/100

objectionary/jeo-maven-plugin#1774 · Opened Sep 21, 2026
Minor breakage w/ LLVM 7: `test_llvm.cpp: error: cannot convert 'llvm::Module' to 'llvm::Module*'` Open

Difficulty 2/5 1-3 hours Newbie friendliness 68/100

lfortran/lfortran#13384 · Opened Sep 21, 2026

More Compilers issues