I checked it for PostgreSQL right now, and it seems that libpq can send them OOB via PQexecParams() and networked integer buffers. But that's not the case with OpenResty's pgmoon driver, which doesn't have such an interface. E.g. Lapis framework built on top of that simply escape_literal()-izes all arguments and interpolates right into query text. So, YMMW with specific (or generic) drivers.

Placeholders are there for those who tries to concatenate queries by hand; having them properly escaped in protocol should not defeat client-side security purpose.

You can never properly escape user input, so this escape_literal() is a ticking timebomb.

How come it's impossible to properly escape user input? I get that it's hard if the format is complex, but I don't see what makes it categorically impossible, especially for a simple format like an SQL string. You just double every single quote and then surround the whole thing with single quotes.

> ...every single quote...

And then you come across \u0027 and you're screwed.

Do you know any decent server that interprets 6-char \uxxxx sequences as part of its top-level query syntax? I mean, how do you safely pass '\u0027' literal to it anyway? If you can't, then its literals and escaping are broken by design, so it is good to know from the start of using it.

Edit: removed double backslash from literal to not confuse it with host language's escaping.

If you use a broken RDBMS, maybe. The standard is quite clear, and that certainly doesn't work in PortgreSQL.

Depends. Server-side prepare works the way you described while client-side prepare interpolates placeholder values. Both are widely used.

Having the interpolation done in one central place and coded by someone experienced sounds as good as OOB to me.

With that central place being?

Lapis db:query("? ?", a, b)

Edit: this call is most low-level db interface in lapis apps.