I assume you mean libraries of SQL code (e.g. query fragments/templates) as opposed to libraries for working with SQL?
I assume you mean libraries of SQL code (e.g. query fragments/templates) as opposed to libraries for working with SQL?
I'm criticizing SQL as a language which is lacking in composability (as opposed to criticizing relational algebra or relational data model).
Libraries for working with SQL (full-fledged ORMs or simpler query builders) are themselves written in a different language so they don't necessarily prove anything about SQL itself, though one could argue that if people want to use them then they might not be satisfied with raw SQL.
Or alternatively, if it's for things that really are mutating state and involving biz logic... a stored procedure.
Date & Darwin proposed the addition of "operators" to the relational algebra in their "Tutorial D" description of alternatives to SQL. That is, instead of "stored procedure", the addition of a type system matching on relations ("tables") and their tuples ("rows") and then the ability to create user-defined programmatic "operators" (a bit like OO methods) for those types.