Cree una cláusula WHERE SQL parametrizada desde filtros

Cada nombre de campo se entrecomilla como identificador SQL, incluidos los segmentos de un nombre cualificado, mientras que los valores quedan fuera del texto SQL. Los filtros conservan su orden original y se unen mediante AND, por lo que el resultado es predecible para generadores de consultas, herramientas administrativas, informes y endpoints que ya reciben filtros como datos.

Construya la estructura SQL sin concatenar valores

Las pantallas de búsqueda dinámica suelen comenzar con registros aparentemente inocuos: un campo, un operador y un valor. El riesgo aparece al convertirlos en SQL insertando el valor directamente en una cadena. Este generador mantiene separados la estructura y los datos. Devuelve una cláusula WHERE SQL parametrizada con marcadores posicionales al estilo PostgreSQL, como $1 y $2, además de un arreglo params exactamente en el orden correspondiente. Inserte la cláusula en una sentencia SELECT, UPDATE o DELETE más amplia y entregue params a un controlador de base de datos compatible. El generador no ejecuta consultas, no se conecta a una base de datos, no inspecciona esquemas ni decide qué columnas puede usar quien llama. Su aplicación debe conservar una lista permitida cuando los usuarios puedan influir en los campos. El entrecomillado evita que la puntuación o las palabras reservadas rompan la sintaxis, pero la autorización sigue siendo responsabilidad de la aplicación. Como los filtros se unen mediante AND en el orden recibido, la salida es estable y fácil de registrar, comparar o combinar con una consulta fija.

Comprenda los operadores, marcadores y controles de nulos

Se admiten operadores de igualdad, desigualdad, comparación de orden, LIKE, NOT LIKE, IN, NOT IN, IS NULL e IS NOT NULL. El texto del operador se normaliza a mayúsculas y los espacios repetidos se reducen, de modo que una escritura como “not like” produce SQL canónico. Cada comparación ordinaria consume un parámetro. IN y NOT IN exigen un arreglo no vacío y lo expanden a un marcador por elemento, sin alterar el orden. Los operadores de nulos no consumen parámetros ni necesitan valor, porque su gramática SQL no incluye marcadores. Si falta el valor para cualquier otro operador, se rechaza la entrada en lugar de generar SQL incompleto. Se aceptan valores escalares JSON, como cadenas, números, booleanos y null; los arreglos se reservan para los dos operadores de lista. El resultado utiliza deliberadamente marcadores numerados con signo de dólar, apropiados para PostgreSQL y bibliotecas compatibles. Si su controlador usa signos de interrogación o parámetros con nombre, traduzca la sintaxis en un adaptador controlado y conserve el orden de parámetros devuelto.

Entrecomille identificadores y valide la política de la aplicación

Cada campo se trata como un identificador posiblemente cualificado. Un nombre como users.created_at se convierte en dos segmentos entrecomillados por separado, y una comilla doble interna se escapa duplicándola según las reglas estándar de identificadores SQL. Se rechazan los nombres vacíos y los segmentos vacíos separados por puntos. Este tratamiento impide que una cadena de campo se confunda con sintaxis SQL sin entrecomillar, pero no afirma que todos los motores utilicen reglas idénticas. Confirme la compatibilidad con su base de datos, sobre todo si no sigue la convención de comillas dobles. Además, escapar no equivale a conceder permisos. Si una persona externa elige campos, asocie las claves públicas de filtro con un conjunto explícito de columnas reales antes de invocar el generador. Aplique también reglas de negocio a los operadores: un endpoint de informes puede permitir igualdad y rangos, pero negar búsquedas por patrones aunque LIKE sea compatible. Todo operador SQL desconocido produce un error de entrada claro en lugar de pasar sintaxis no reconocida. La capacidad es determinista, no realiza solicitudes de red y devuelve únicamente la cláusula y sus parámetros.