libpq-9.2 introduces a new function PQsetSingleRowMode, which should be added to these bindings at some point.
However, I'm not entirely sure how we should deal with this. It seems like we'll need some level of detection of the version of libpq that we are compiling against, and then use some conditional compilation. To do this, it appears the best way would to be to modify Setup.hs to use the cabal hooks to run pg_config.libpq-dev to get the version, and then auto-generate a header file in the spirit of dist/build/autogen/cabal_macros.h. I did briefly investigate tweaking the generation of this file directly, but I don't think this is a good idea.
The next question is how this relates to the Package Version Policy, as postgresql-libpq's interface would no longer be a function of it's version, but also of the version of libpq it's compiled against.
Perhaps it would be a good idea to include a dummy, no-op implementation when PGsetSingleRowMode is not available. This would present a consistent interface at the module signature level, though not entirely at the semantic level. I suppose it might be possible for a no-op implementation to cause deadlocks or other problems.
At least it signals whether or not the call was successful, so the no-op can simply return false all the time, which would be somewhat consistent with the actual function.
lpsmith
commented
8 years ago
libpq-9.2 introduces a new function PQsetSingleRowMode, which should be added to these bindings at some point.
However, I'm not entirely sure how we should deal with this. It seems like we'll need some level of detection of the version of libpq that we are compiling against, and then use some conditional compilation. To do this, it appears the best way would to be to modify
Setup.hsto use the cabal hooks to runpg_config.libpq-devto get the version, and then auto-generate a header file in the spirit ofdist/build/autogen/cabal_macros.h. I did briefly investigate tweaking the generation of this file directly, but I don't think this is a good idea.The next question is how this relates to the Package Version Policy, as postgresql-libpq's interface would no longer be a function of it's version, but also of the version of libpq it's compiled against.
Perhaps it would be a good idea to include a dummy, no-op implementation when
PGsetSingleRowModeis not available. This would present a consistent interface at the module signature level, though not entirely at the semantic level. I suppose it might be possible for a no-op implementation to cause deadlocks or other problems.At least it signals whether or not the call was successful, so the no-op can simply return false all the time, which would be somewhat consistent with the actual function.