Planteamiento y contexto
El sistema debe encontrar un nombre de usuario o correo electrónico a partir de la entrada del usuario utilizando Unicode Default Caseless Matching. Explica cómo evaluarías casefold() de PostgreSQL 18, elegirías una intercalación (collation), crearías índices y migrarías los datos existentes. No te limites a una sola llamada de función.
Qué evalúa el entrevistador
- Saber que el case folding difiere de una simple conversión a minúsculas y puede expandir un carácter en varios.
- Verificar UTF-8, el proveedor de intercalación (collation provider) y las restricciones específicas del despliegue.
- Explicar índices basados en expresiones, unicidad, normalización y el orden de migración.
- Diseñar detección de conflictos, reversión (rollback), validación de rendimiento y reglas de cara al usuario.
Preguntas aclaratorias para hacer
- ¿El requisito es Unicode default caseless matching o una regla de ordenamiento específica de una configuración regional (locale)?
- ¿Esto es para búsquedas, coincidencias de inicio de sesión o unicidad global después de la normalización?
- ¿Los datos existentes pueden contener ß, letras griegas o caracteres combinados? ¿Puede cambiar el valor visualizado?
- ¿Cuáles son la codificación de la base de datos, el proveedor de intercalación, la versión y la ventana para cambios de índices en línea?
Estructura de respuesta en 30 segundos
Confirmaría la semántica de coincidencia y unicidad, y luego verificaría UTF-8 y una intercalación que admita case folding. casefold() debe generar una clave de comparación, no reemplazar el valor visualizado; algunos caracteres se expanden y un proveedor libc puede comportarse como lower(). Generaría claves fuera de línea y encontraría conflictos antes de crear un índice basado en expresiones o una restricción de unicidad con clave almacenada, y luego migraría lecturas y escrituras por etapas mientras monitoreo los planes de consulta. Deben probarse muestras multilingües representativas, el uso de índices, los cambios de longitud y la reversión antes del lanzamiento.
Análisis detallado paso a paso
1. Definir el límite de coincidencia y visualización
Almacena el valor original por separado de la clave de comparación. Decide si también se requieren normalización Unicode, eliminación de espacios en blanco o reglas específicas de correo electrónico; casefold solo maneja el case folding.
2. Verificar codificación e intercalación
La documentación requiere la codificación de servidor UTF-8. El case folding depende de la intercalación: una intercalación de Unicode puede plegar ß en ss, mientras que un proveedor libc sin soporte para case folding hace que casefold sea equivalente a lower. Ejecuta muestras representativas en el entorno de destino antes del despliegue.
3. Diseñar índices y unicidad
La búsqueda puede utilizar un índice basado en expresiones sobre casefold(column). Para la unicidad, decide si la clave de comparación se persiste y cómo se resuelven los conflictos históricos. No asumas que la longitud del resultado no cambia ni permitas que la columna de visualización aplique la identidad.
4. Migrar y validar de forma segura
Escanea las filas existentes en busca de claves plegadas iguales, define reglas de fusión o resolución manual, luego realiza el backfill y agrega restricciones por etapas. Valida con EXPLAIN, muestras multilingües similares a producción, escrituras concurrentes y reintentos; pausa la transición (cutover) y mantén un interruptor de reversión cuando aparezcan conflictos.
Respuesta modelo
Trataría a casefold() como una regla de clave de comparación, no como una transformación de visualización. Confirmaría Unicode Default Caseless Matching, la codificación UTF-8 y el comportamiento de la intercalación de destino para caracteres como ß, y luego verificaría el proveedor, ya que el plegado no compatible en libc recurre a lower(). Escanearía las filas existentes en busca de conflictos de claves plegadas, elegiría una clave almacenada o un índice basado en expresiones y crearía la restricción de unicidad correspondiente. La migración realizaría el backfill y la escritura dual por etapas, con pruebas de planes de consulta, concurrencia, multilingües y de reversión. Los usuarios verían el valor original mientras la regla de coincidencia se mantiene explícita.
Errores comunes
- Tratar a
casefold()como un simple alias delower(). - Ignorar las diferencias de UTF-8, intercalaciones y proveedores.
- Asumir que la salida plegada mantiene la misma longitud y truncarla.
- Agregar una restricción de unicidad antes de escanear conflictos históricos.
- Sobrescribir el valor de visualización con la clave de comparación.
- Probar solo la funcionalidad y no los planes de índices basados en expresiones sobre datos multilingües.
Preguntas de seguimiento y respuestas
¿Puede casefold reemplazar la normalización?
No. Maneja el case folding; los caracteres combinados, los caracteres de compatibilidad y la limpieza de negocio necesitan reglas de normalización independientes cuyo orden debe ser probado.
¿Por qué ß es un caso de prueba útil?
Con intercalaciones como PG_UNICODE_FAST, ß puede plegarse a ss. El cambio de longitud expone de inmediato los supuestos de diseño en coincidencia, tamaño de campos y unicidad.
¿Qué riesgo introduce el proveedor libc?
La documentación indica que sin soporte de case folding, libc hace que casefold sea equivalente a lower. Fija la intercalación/proveedor y ejecuta pruebas de migración y regresión en un entorno similar a producción.