Consider migrating ClickHouse UUID type to SQLAlchemy native UUID

[Leechael]

Context

clickhouse_sqlalchemy.types.UUID is a project-local UUID type. It was introduced in 2020 when the project supported SQLAlchemy 1.x, before SQLAlchemy 2.0 added the built-in Uuid and UUID types.

Now that the project targets SQLAlchemy 2.x, we should evaluate whether the ClickHouse UUID type can be aligned with or replaced by SQLAlchemy's native UUID support.

Current behavior

• clickhouse_sqlalchemy.types.UUID subclasses the project String type and uses __visit_name__ = 'uuid'.
• It currently has a custom literal_processor that renders Python uuid.UUID values through SQLAlchemy string literal rendering.
• The ClickHouse dialect currently reports supports_native_uuid = False, so SQLAlchemy's built-in UUID() / Uuid() render UUID literals as compact 32-character hex strings for this dialect.
• ClickHouse accepts native UUID values and the existing ClickHouse type renders hyphenated UUID strings.

Example observed behavior:

clickhouse_sqlalchemy.types.UUID(): '00000000-0000-4000-8000-000000000021'
sqlalchemy.UUID() with supports_native_uuid=False: '00000000000040008000000000000021'

Proposal

Evaluate a formal migration path instead of keeping a bespoke UUID implementation indefinitely:

1. Decide whether the ClickHouse dialect should set supports_native_uuid = True.
2. Decide whether clickhouse_sqlalchemy.types.UUID should alias/subclass SQLAlchemy's UUID.
3. Preserve public import compatibility, e.g. from clickhouse_sqlalchemy import types; types.UUID().
4. Add explicit bind/result/literal tests for UUID behavior.
5. Verify asynch, HTTP, and native driver paths.

Test coverage to add or verify

• Direct literal_processor unit test for Python uuid.UUID.
• SQLAlchemy literal_binds=True compilation test.
• Real ClickHouse integration round trip for UUID and Nullable(UUID).
• String UUID and Python uuid.UUID inputs.
• Return type expectations when as_uuid=True / as_uuid=False, if supported.

Notes

This should not be handled as part of the current PR. It is a compatibility/design migration issue and should be evaluated separately.