Internally, Npgsql sometimes prepends commands, adding them to its internal buffer but without actually sending them to PG; they are then sent when the user next executes a command. The main cases are:

• NpgsqlConnection.BeginTransaction: we don't do an extra roundtrip for this.
• Connection state reset when it's returned to the pool (DISCARD ALL): no extra roundtrip (which would kill pool perf).

In some situations, it may be userful for users to do something like this. I thought about this specifically in the context of multi-tenancy, where users want to set some tenant-specific state after getting a connection from the pool; for example, when doing schema-per-tenant, it's typical to want to set the SEARCH_PATH session parameter every time.

Design:

• We can expose a simple API on NpgsqlConnection that accepts SQL and sends it via the simple protocol (this means no parameters).
• For a full API, we could instead add a PrependNonQuery (or ExecuteNonQueryDeferred?) method on NpgsqlCommand, similar to ExecuteNonQuery. This would allow using parameters and everything else, via the extended protocol.
• Note that this doesn't make sense with multiplexing, since there's no state there.

/cc @ajcvickers