Describe the bug
Using server_default=sa.null() in an alter_table command triggers a typing error, even though the migration executes without any problems.

Note also that sa.null() is type checked properly when used in a column definition like sa.Column("description", sa.Text, nullable=True, server_default=sa.null())



Expected behavior
No typing errors should be raised for valid code.

To Reproduce
The following valid code produces a typing error

def upgrade():
    op.alter_column(
        "table_name",
        "column_name",
        server_default=sa.null(),
        nullable=True,
    )

Error

error: Argument "server_default" to "alter_column" has incompatible type "Null"; expected "str | bool | Identity | Computed | TextClause | None"  [arg-type]

Versions.

• Python: Python 3.12.9 (main, Feb 12 2025, 15:09:19) [Clang 19.1.6 ] on darwin
• Alembic: 1.16.1
• SQLAlchemy: 2.0.40
• Database: postgres
• mypy: mypy 1.15.0 (compiled: yes)

Additional context
This happens because there are some inconsistencies on how server_default is typed throughout alembic's and sqlalchemy's codebases.

Sqlalchemy types server_default on Column as _ServerDefaultArgument, which is defined as


_ServerDefaultArgument = Union["FetchedValue", str, TextClause, ColumnElement[Any]]

Whereas on alembic there are 2 definitions.
The signature exposed on op.pyi types server_default as

Union[str, bool, Identity, Computed, TextClause, None]


The signature defined on alembic.ddl.impl types server_default as Optional[Union[_ServerDefault, Literal[False]]], where _ServerDefault is defined as

_ServerDefault = Union["TextClause", "FetchedValue", "Function[Any]", str]