Rolling back to a savepoint doesn't release it so,
reusing the same name in nested transaction means
inner transactions only roll back to the
most transaction/last savepoint.
If the outer most transaction commits but did multiple
consecutive rollbacks in the nested transactions this
did cause an unexpected state in the database before
the fix.
This provides a lot more flexibility around version support, and unlike
the ToSql/FromSql implementations, these don't actually need to be in
postgres itself.
Also add the version number to the feature name. This both makes it more
obvious when using them and opens the window for support of multiple
versions simultaneously in the future.
The simple query API is a more robust version of `batch_execute`. Like
that method, `simple_query` allows passing a `&str` of semicolon
delimited queries. Divergence from `batch_execute` is in the return
type; instead of nothing, a `Vec<TextRows>` is returned. Each entry in
this `Vec` is the result set of one query in the query string. Thus if
there are two semicolon delimited queries, there will be two entries in
this `Vec`.
The `TextRows` and `TextRow` types returned from `simple_query` closely
mirror existing `Rows` and `Row` types with one major difference: only
string values can be retrieved from them.
There are a few TODOs in the code:
* Are text values in this case guaranteed to be utf-8 encoded?
* unwrap call in simple_query which assumes RowDescription is always
sent
* documentation (denoted with either STUB or TODO)
This allows for in-place deserialization of text and bytea values in
particular.
Row::get_bytes is removed since it previously existed for this use case.
Closes#281
Handle the error that is generated when the DB connection goes down instead of panicing with
an unreachable code error. This allows the notification client to retry establishing the
connection instead of crashing the complete program.
