Custom notice processing.

[torgeirsh]

Notices from the server are usually printed to standard error by libpq in defaultNoticeProcessor. Some applications may want to log these notices in a different way, but postgresql-libpq seems to only offer a way to disable them with disableNoticeReporting. Could a way to override notice processing with PQsetNoticeProcessor be exposed in postgresql-libpq?

[phadej]

There is enableNoticeReporting which let you poll notices with getNotice.

Also @nh2 used custom Haskell notice reporting in #19, but I have no idea what he did (i.e. did he poke with internals directly?)

[nh2]

Also @nh2 used custom Haskell notice reporting in #19, but I have no idea what he did (i.e. did he poke with internals directly?)

I also used it to "log these notices in a different way" as @torgeirsh says.

Code snippet (using inline-c):

        -- set the notice processor callback so it doesn't spam stdout
        noticeProcessorFunPtr <- liftIO $ $(C.mkFunPtr [t|Ptr () -> CString -> IO ()|]) $ \_ noticeCString -> do
          noticeString <- peekCString noticeCString
          unliftIO io $ logInfo $ it $ "Postgres: "##noticeString
        liftIO $ withLockedSimpleConnAsPqConn connection $ \pqConnection ->
          LibPQ.withConn pqConnection $ \cConnection ->
            [C.exp| void {
               PQsetNoticeProcessor($(PGconn* cConnection), $(void (*noticeProcessorFunPtr)(void *, const char *)), NULL)
            } |]
        return (connection, PostgresNoticeProcessorFunPtr noticeProcessorFunPtr)


newtype PostgresNoticeProcessorFunPtr = PostgresNoticeProcessorFunPtr (FunPtr (Ptr () -> CString -> IO ()))

-- | Allows using the lower-level `postgresql-libpq` connection inside a
-- `postgresql-simple` connection.
--
-- Like `postgresql-simple`'s `SQL.withConnection`, but lifted to `MonadUnliftIO`.
--
-- It is generally strongly advised to use `postgresql-simple`'s connection
-- (in combination with this function), because it ensures with an MVar lock
-- that operating on a closed `free()`d underlying C `PGconn` is excluded
-- (thus protecting multi-threaded use from segfaults).
--
-- This wrapper also makes clear with its name that using it takes the
-- connection lock, suggesting to make the amount of work that needs this
-- lock as small as possible.
withLockedSimpleConnAsPqConn :: (MonadUnliftIO m) => SQL.Connection -> (LibPQ.Connection -> m a) -> m a
withLockedSimpleConnAsPqConn conn cont = withRunInIO $ \run -> SQLInternal.withConnection conn (\pqConn -> run (cont pqConn))

[phadej]

@nh2 ok, so you did poke with internals directly (i.e. called C functions yourself).

I think we can add wrappers to PQsetNoticeProcessor to postgresql-libpq to make that more convenient. (And justify setting every FFI call to safe - as they could remained unsafe if your usage would been considered wrong). I wrongly assumed that setting own notice processor was already supported.

[nh2]

Yes, I should also say I did that because I did not want to use a second thread, but get a callback for easier order guarantees, less risk of deadlocking, etc.