Build a parameterized SQL WHERE clause from filters

Every field name is quoted as an SQL identifier, including each segment of a qualified name, while values remain outside the SQL text. Filters are kept in their original order and joined with AND, making the result predictable for query builders, admin tools, report screens, and server endpoints that already collect filters as data.

Build SQL structure without concatenating values

Dynamic search screens often begin with harmless-looking records such as a field, an operator, and a value. The dangerous step is turning those records into SQL by inserting the value directly into a string. This builder keeps structure and data separate. It returns a parameterized SQL WHERE clause containing PostgreSQL-style positional placeholders such as $1 and $2, plus a params array in exactly the matching order. Pass the clause into the larger SELECT, UPDATE, or DELETE statement and give the params array to a compatible database driver. The builder does not execute a query, connect to a database, inspect a schema, or decide which columns a caller may use. Your application should still maintain an allowlist when users can influence field names. Identifier quoting prevents punctuation and reserved words from breaking the generated syntax, but authorization remains an application concern. Because filters are joined by AND in the supplied order, the output is stable and easy to snapshot, log, compare, or combine with an existing fixed query prefix.

Understand operators, placeholders, and null checks

The supported comparison operators are equality, inequality, ordering comparisons, LIKE, NOT LIKE, IN, NOT IN, IS NULL, and IS NOT NULL. Operator text is normalized to uppercase and repeated whitespace is collapsed, so a human-friendly spelling such as “not like” produces canonical SQL. Every ordinary comparison consumes one parameter. IN and NOT IN require a non-empty value array and expand it into one placeholder per element, preserving array order. Null-check operators consume no parameter and do not require a value because their SQL grammar contains no placeholder. A missing value for any other operator is rejected instead of silently generating incomplete SQL. JSON scalar values are accepted, including strings, numbers, booleans, and null; arrays are reserved for the two list operators. The result deliberately uses numbered dollar placeholders, which suit PostgreSQL and libraries that accept that convention. If your driver uses question marks or named parameters, translate the placeholder syntax in a controlled adapter while preserving the returned parameter order.

Quote identifiers and validate application policy

Each field is treated as a possibly qualified identifier. A name such as users.created_at becomes two separately quoted segments, while an embedded double quote is escaped by doubling it according to standard SQL identifier rules. Empty names and empty dotted segments are rejected. This treatment stops a field string from being confused with unquoted SQL syntax, but it intentionally does not claim that every database engine has identical quoting behavior. Confirm compatibility with your target database, especially if it does not follow double-quoted identifier conventions. More importantly, escaping is not the same as permission. If an external caller selects fields, map public filter keys to an explicit set of real columns before invoking the builder. Do the same for business-level operator rules: a reporting endpoint may permit equality and ranges while refusing pattern searches even though the builder supports LIKE. Unsupported SQL operators always produce an input error, which gives callers a clear failure instead of passing unfamiliar syntax through. The capability is deterministic, performs no network requests, and returns only the clause and parameters.