Determine level of effort to replace libpq with native chapel

[buddha314]

We appear to be having issues with libpq and contention locking in CDO. If that is unresolvable (and expect a ticket to examine that) we should try to determine the LOE (Level of Effort) on building a native Chapel postgres driver that does not include libpq.

[ben-albrecht]

Is this the source of libpq?

[marcoscleison]

yes, although I use it from my ubuntu repository.

[marcoscleison]

At first, I would like to know if the issue is in CDO. But if it is in the interaction between Chapel and libpq have the opportunity to develop a native driver of the postgres in Chapel.
Pros:
It allows better integration.
it allows safer use in a parallel environment.
it has wire protocol documentation.
Cons:
Takes time
Needs a thread-safe TCP client example in Chapel.
Needs auxiliary modules like base64 encoder decoder.
Although postgres wire protocol is not hell difficult it is not trivial.

I am motivated to develop the native driver, but I will need to have some help with some specifics things.

[ben-albrecht]

It's probably worth spending more time understanding the bug in #23 before rewriting libpq in Chapel. For example, it's not clear to me if rewriting libpq in Chapel would resolve this issue, based on the info currently available.

[marcoscleison]

Only for documentaton:
https://www.postgresql.org/docs/9.3/static/protocol-flow.html
https://www.pgcon.org/2014/schedule/attachments/330_postgres-for-the-wire.pdf