Add pipeline mode API

[robx]

This wraps the pipeline mode API, introduced in PostgreSQL 14: https://www.postgresql.org/docs/current/libpq-pipeline-mode.html

I'm not sure how the version requirement should be handled.

(For the moment we're using this experimentally here: PostgREST/postgrest#2707.)

[robx]

there's a name clash between PGRES_PIPELINE_ABORTED and PQ_PIPELINE_ABORTED

[robx]

I updated CI to use Ubuntu 22.04 (Jammy) to provide libpq version 14 -- clearly that doesn't really solve the versioning question. (There's some failures now on older GHC versions: It looks like there's some incompatiblity between Ubuntu 22.04 and the hvr-ppa setup method.)

[GulinSS]

Did similar here but had a look at PR's before send my one :)

Your version is clearer than mine and it has better tests. @robx what do you think regarding my approach with cabal compile flag to tweak which version of libpq is linked? Could you add it to your PR or should I do it?

[nikita-volkov]

@phadej Hi! Can you help us get this merged?

[phadej]

I'm unsure. The versioning question is hard. There are options:

• Always use pkg-config. (Windows users will suffer AFAIU, I don't know if pkg-config can be made work with usual ways postgresql is installed on windows). I'm fine with this myself (I'd only need to figure out pkg-config problem on CI). That would allow me to remove build-type: Custom which I'd be very happy to do.
• Assume that postgresql version is always recent enough if pkg-config method is not used.

And there are variants:

• Add a (manual) flag whether to include pipeline mode or not. (The library API should be the same, functions will just fail if there are no support).
• Always require recent enough libpq (people may use older libpq releases if they cannot upgrade - which is fine, as they won't get much by upgrading).

Opinions?

[nikita-volkov]

I may be wrong, but I think that unless the functions that aren't supported by the old libpq actually get used, things will work fine. If that's correct then there seems to be no need for the flags. Instead stating this clearly in the docs shall be enough.

[phadej]

I may be wrong, but I think that unless the functions that aren't supported by the old libpq actually get used,

foo :: Maybe Int -> IO Int
foo (Just x) = return x
foo Nothing  = bar

foreign import ccall "does_not_exist" bar :: IO Int

Even if I do

Prelude Lukko> foo (Just 1)

GHC.Linker.Loader.dynLoadObjs: Loading temp shared object failed
During interactive linking, GHCi couldn't find the following symbol:
  /tmp/ghc57176_0/libghc_37.so: undefined symbol: does_not_exist

things fail. So when linker decides to load symbols is not very predicatable.

I'd expect static builds to fail, except in very happy situations where dead code elimination can actually prune everything mentioning "new" functions.

[nikita-volkov]

Thanks for the clarification!

How about using the flag but have it default to requiring the latest libpq? Thus the library will effectively apply the following strategy:

Always require recent enough libpq

Which seems like an essential requirement for this library and the whole downstream ecosystem to evolve.

However it will also leave the alternative option available for hackers willing to use the older version.

[phadej]

@nikita-volkov that's my option

Add a (manual) flag whether to include pipeline mode or not. (The library API should be the same, functions will just fail if there are no support).

isn't it?

[nikita-volkov]

If it implies that the default is to enable the new functions, then it is.

[GulinSS]

Posted version with cabal flag to support older libpq versions.

[robx]

Closing this one in favour of #52 (but feel free to reopen if that seems like a better idea)

[phadej]

Released in https://hackage.haskell.org/package/postgresql-libpq-0.11.0.0