This is a request to expose the functionality of Database.PostgreSQL.Simple.Internal.PQResultUtils. Similarly to Database.PostgreSQL.Simple.Internal, it doesn't need to be a stable API but it would really help external writers implement their own versions of query which can have slightly different hooks than postgresql-simple does without reimplementing (or copy/pasting!) the contents of PQResultUtils.hs.
For instance, a caching mechanism can be implemented by checking if a query is in the cache, and if so running the specified parser on the cached result bytes. It would be more maintainable if it could rely on postgresql-simple's well-developed parsing infrastructure instead of reimplementing it.
Another example is if somebody wanted to implement a binary client, they could simply write new binary parsers but still reuse postgresql-simple's Connection and result handling infrastructure.
I can submit a PR for this if it sounds acceptable
This is a request to expose the functionality of
Database.PostgreSQL.Simple.Internal.PQResultUtils
. Similarly toDatabase.PostgreSQL.Simple.Internal
, it doesn't need to be a stable API but it would really help external writers implement their own versions ofquery
which can have slightly different hooks thanpostgresql-simple
does without reimplementing (or copy/pasting!) the contents ofPQResultUtils.hs
.For instance, a caching mechanism can be implemented by checking if a query is in the cache, and if so running the specified parser on the cached result bytes. It would be more maintainable if it could rely on
postgresql-simple
's well-developed parsing infrastructure instead of reimplementing it.Another example is if somebody wanted to implement a binary client, they could simply write new binary parsers but still reuse
postgresql-simple
's Connection and result handling infrastructure.I can submit a PR for this if it sounds acceptable