LargeBinary binds or raises depending on whether the value happens to be valid UTF-8

Cerrado
  • ¿Algo no está bien?
#80 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@dwaddle ya está trabajando en esto.

Desde el 17/10/2026.

  • #82 de @dwaddle — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
database

Línea de trabajo

Comienza localizando el punto de entrada de la representación de parámetros o literales del dialecto y el manejo existente de LargeBinary. Reproduce los ejemplos de UTF-8 no válido y, después, implementa la representación hex/unhex sugerida para bytes. Se considera terminado cuando los valores binarios, incluido b'\x00\xff', se insertan y se recuperan idénticamente sin depender de la validez de UTF-8.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Versions

  • databend-sqlalchemy 0.5.5
  • databend-driver 0.34.2
  • SQLAlchemy 2.0.51
  • Python 3.12.9, macOS
  • Server: datafuselabs/databend:v1.2.925-patch-4 in Docker

What happens

The dialect renders parameters into the statement text, so a bytes value gets decoded as UTF-8 on the way in. Whether a LargeBinary insert works therefore depends on the value, not the type. One value at a time, everything else held constant:

value valid UTF-8 result
b'\x00\x01' yes binds, round-trips identically
b'abc' yes binds, round-trips identically
b'\xc3\xa9' yes binds, round-trips identically
b'\x00\xff' no 'utf-8' codec can't decode byte 0xff in position 1
b'\xff' no same
b'\x80' no same

The database is not the problem. A BINARY column given unhex('00ff') reads back as b'\x00\xff' without complaint.

Why this one bothered me

Valid UTF-8 isn't a property binary data has. So the column works right up until the day the bytes have a high one in them — and a test suite with ASCII-ish fixtures will never see it. That's worse than a flat refusal, because a refusal gets found on day one. I ended up declaring LargeBinary unstorable on this dialect rather than let it fail per value, which loses a column type the database supports perfectly well.

Suggested fix

Hex-encode bytes parameters and emit unhex('…') — the server already accepts that, as above.

Some background, in case it's useful: databendlabs/bendsql#583 asked for real parameter binding in the driver, and interpolating into statement text is what makes bytes unrepresentable here. For what it's worth, trino-python-client gets this wrong from the identical cause — its literal formatter calls .encode() on the value, which is what you'd do to a str. Interpolating parameters into SQL seems to be what gets bytes wrong, whoever does it.

Lenguaje dominante
Python
Estrellas
15
Forks
5
Merge medio
1 d 15 h
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de databendlabs/databend-sqlalchemy

Todos los issues de databendlabs/databend-sqlalchemy

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.