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

Bytestring Renderer #79

Closed
csasarak opened this issue Jul 2, 2019 · 4 comments
Closed

Bytestring Renderer #79

csasarak opened this issue Jul 2, 2019 · 4 comments

Comments

@csasarak
Copy link

csasarak commented Jul 2, 2019

Would there be any interest in accepting a PR which outputs a Doc directly to a Bytestring?

@quchen
Copy link
Owner

quchen commented Jul 5, 2019

Bytestrings don’t contain text, and this would be an additional dependency. I don’t think this is a good idea. Is there a sprecific use case you need this for?

@csasarak
Copy link
Author

csasarak commented Jul 5, 2019

It is primarily for this PR I'm working on: tomjaguarpaw/haskell-opaleye#436

We were looking at switching to prettyprinter for rendering SQL queries. The underlying library, postgresql-simple accepts a bytestring. For now, we render to text and then use encodeUtf8 of the text library to turn it into a bytestring. I was going to see if it would be faster to turn a SimpleDocStream into a bytestring directly via the Builder interface instead of going to text and then to bytestring.

@quchen
Copy link
Owner

quchen commented Jul 5, 2019

I see. Since using Bytestring is a quirk of postgresql-simple (which should really use Text I guess), I think the right place for the renderer would be in Opaleye. It’s not really a lot of code to write your own renderer (see e.g. the ShowS renderer).

I’m not sure you’ll gain much performance in the process though, since Prettyprinter uses Text internally anyway. Writing your own renderer would have to convert the contained Text to Bytestring and then concatenate those, as opposed to simply rendering to one big Text value and then encoding that as a whole like in the straightforward solution.

@csasarak
Copy link
Author

csasarak commented Jul 5, 2019

Thank you for that insight, I agree it probably doesn't make sense to do it that way anyhow. I'll close this.

@csasarak csasarak closed this as completed Jul 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants