Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using postgresql-wire instead of postgresql-libpq #63

Open
chshersh opened this issue Sep 21, 2018 · 7 comments
Open

Consider using postgresql-wire instead of postgresql-libpq #63

chshersh opened this issue Sep 21, 2018 · 7 comments
Labels

Comments

@chshersh
Copy link
Contributor

postgresql-wire implements native PostgreSQL driver which is much better for performance and GC.

@echatav
Copy link
Contributor

echatav commented Sep 21, 2018

Does postgres-wire provide a similar interface to postgresql-libpq? I'd need things like the Result type and exec, execParams, execPrepared, and prepare functions. Would you want to see it replace postgresql-binary as well? It looks like it has a bunch of codec logic. Squeal cannot depend on a library that's not on Shtackage but if it gets theres and is a good replacement, native Haskell has many advantages over C.

@chshersh
Copy link
Contributor Author

Putting postgresql-wire on Stackage shouldn't be a problem. But, unfortunately, it's not even on Hackage which is a problem...

Regarding the rest: I'm not an expert in postgres-wire library, but I would like to have high level interface on top of the efficient backend.

Maybe @VyacheslavHashov or @qnikst can clarify things.

@qnikst
Copy link

qnikst commented Sep 21, 2018

I think it may be a bit of premature, at the current stage we will be working to wrapping everything up on the library level itself and try writing adapters for other libraries, then we can come with best practices and suggestions how higher-level libraries may try to use it.
As far as I understand postgresql-simple design in concentrated around synchronous text protocol, so it may be very hard to write a compatible adapter to allow drop-in replacement.
In the next few weeks, we will try to get more understanding of those questions and I'll get back to this thread.

@reygoch
Copy link

reygoch commented Oct 12, 2018

@chshersh @qnikst Hasql might be a better option since it's on Hackage and Stackage and it is a native driver.

@qnikst
Copy link

qnikst commented Oct 13, 2018

@reygoch it's not entirely correct. hasql at least version on hackage is not a native driver, it's using libpg but the binary protocol. Despite the fact that hasql is a very nice library it inherits all the problems coming from libpg.

@reygoch
Copy link

reygoch commented Oct 13, 2018

@qnikst sorry, forgot to mention that author uses a bit convoluted versioning system. You want to look at v0.20.1. It is quite nice and soon to be released.

There is also a nice talk by the author explaining the functionality of the library.

This part of the talk might interest you in particular (11:18).

@ilyakooo0
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants