It probably does make sense to provide this for these kinds of use cases. I think placing the function in the postgres-protocol crate and sticking some sternly-worded docs on it should be sufficient to discourage overuse.

It isn't possible to put it in postgres-protocol from what I can see due to the dependency on the first field's PGconn:

/* Quoting strings before inclusion in queries. */
extern size_t PQescapeStringConn(PGconn *conn,
				 char *to, const char *from, size_t length,
				 int *error);
extern char *PQescapeLiteral(PGconn *conn, const char *str, size_t len);
extern char *PQescapeIdentifier(PGconn *conn, const char *str, size_t len);

Do you have a suggestion on where it should go given this?

I created PR #702 to address this.

I don't think PQescapeStringConn is necessary. It doesn't provide much value over PQescapeLiteral for new applications, and as you say, it requires the connection object which is annoying.

PQescapeLiteral in libpq does take the connection object as well, but it's only used to determine the client encoding, and report errors. Neither seems relevant because rust-postgres always uses UTF-8 and doesn't try to handle out-of-memory errors.

So I implemented it in postgres-protocol by just porting the libpq code to rust.