[MSSQL-Django] Expose SQL Server type constants (SQL_SS_TIME2, SQL_SS_XML, SQL_SS_VARIANT) at module level #763

What

mssql_python does not expose the SQL Server-specific ODBC type constants at the package level, even though they already exist in the internal ConstantsDDBC enum. pyodbc exposes them as module-level attributes:

• SQL_SS_TIME2 = -154
• SQL_SS_XML = -152
• SQL_SS_VARIANT = -150

In mssql_python these are reachable only via mssql_python.constants.ConstantsDDBC.SQL_SS_TIME2.value. mssql_python.SQL_SS_TIME2 raises AttributeError.

Why it matters

Code written against pyodbc reads these constants off the driver module directly. Django's SQL Server backend is a concrete example: its introspection maps the time column type using Database.SQL_SS_TIME2, where Database is the imported driver module. Against pyodbc that resolves. Against mssql_python it raises AttributeError, so the consumer has to add a fallback:

SQL_SS_TIME2 = getattr(Database, "SQL_SS_TIME2", -154)

That hard-codes an ODBC type code in every consumer, which is exactly what the driver should own. Exposing the constant at module level removes the fallback and keeps mssql_python drop-in compatible with pyodbc for this surface.

Repro

import mssql_python
import pyodbc

print(pyodbc.SQL_SS_TIME2)        # -154
print(mssql_python.SQL_SS_TIME2)  # AttributeError: module 'mssql_python' has no attribute 'SQL_SS_TIME2'

Proposed fix

Promote the SQL Server type constants that pyodbc exposes (SQL_SS_TIME2, SQL_SS_XML, SQL_SS_VARIANT) to module-level public API, following the existing pattern already used for SQL_VARCHAR, SQL_GUID, and the rest. The values already live in ConstantsDDBC, so this is a re-export plus __all__ and type-stub updates, with no new values.

Open question

ConstantsDDBC also defines SQL_SS_UDT (-151) and SQL_DATETIMEOFFSET (-155). pyodbc does not expose either at module level, so this proposal leaves them internal to keep the public surface aligned with pyodbc. They can be added if there is a reason to.