> A DSL cannot do that in general.  You need the connection object to be
> able to get escaping right; it's dependent on database settings,
> especially to the character encoding.

For sure. I was conflating the DSL and the driver interface for the
purposes of this (sub-)discussion.

>> As a separate question, how do you send blobs without parameters?
>
> By using a database-specific escape syntax.  In Postgres you can use
> C-like backslash escaping of non-ASCII characters like \012, or fully
> hex encoded strings starting with \x like '\xf0012345'.

This would be the tie breaker for me. Any approach where you start
escaping blobs sends a strong signal of "there has to be a better way".

The hex syntax is not too bad, but it's postgres-only. And there are
situations where it makes sense to store multi-megabyte blobs in
databases, so avoiding bytevector->string->bytevector conversions is good.

If there's some database that doesn't have parameters at all, I'd just
leave it unsupported. We have to rely on basic amenities at the other
end for us to do our job well. Hopefully the DB implementors listen to
feedback so they can add parameters to a later version which we can then
support.

> I'm also a massive believer in better tools.  Even great programmers have
> momentary lapses in clarity of thinking.

Definitely. One of the main problems is the quantity of code we need to
write to get things done. Many times, good programmers know how to do a
perfect job of something, but it's so much effort relative to the payoff
that they don't. That's one reason layered approaches are often a win.

And if people do a perfect job of laborious tasks, it encourages people
to make more tools that require sustaining that level of effort to do
things well. Tragically the opposite (if people refuse to put in effort,
it encourages the industry to switch to powerful, well-abstacted tools)
doesn't seem to be true :D