Repository navigation
Haskell Summer of Code 2018? #242
Description
I'm planning to propose a few ideas for pg-simple in HSoC 2017. Is anyone else interested in mentoring? Importantly, can we get a time-window where PRs are actively reviewed and merged?
Off the top of my head:
- Fix error messages
- Benchmark and improve performance
- Implement bind/execute
- Fix "hodor" parsing
Activity
lpsmith commentedon Dec 27, 2017
Well, considering my personal needs, postgresql-simple is currently on the backburner, though I want to try to get a release out within the next week or two. I don't know what this coming year has in store for me, but the most reliable way to get and keep my attention would be to pay for my time, which is available through Iterative Systems. I may be interested in mentoring.
I'm absolutely in favor of the first two issues you list. I'm not sure exactly what you mean by the third, do you mean parameter-level protocols? I'm in favor of that, though it's quite a lot of work, and it may be tricky to maintain backwards compatibility and have a nice API in the end. If you mean Postgres's SQL commands PREPARE and EXECUTE, maybe, but I'm less enthusiastic. (As things currently stand, there is nothing stopping people from using those via the public API.)
The fourth issue is kinda tricky. I understand why you might see the current parsing interface as a bit silly, but it's actually capable of much more, it's just that typical parsing needs are simple. For the common 'hodor' case, there are
Genericinstances forFromRowandToRowthat need to be documented, and it might be nice to include some form of Template Haskell as an alternative.That said, I am not entirely satisfied with the parsing interface, and am very much interested in improving it. What I'd like to see is some kind of type-level programming so that we could hoist type-checking to once-per-result instead of the current once-per-row, and also be able to know what rows are consumed by a parser so that we could (for example) write a generic
instance FromRow a => FromRow (Maybe a). How well this would fit into a HSoC type of project I'm less than clear about, as there are a lot of unknowns here that I think have a high chance of leading to failure (of at least this part of the project.)saurabhnanda commentedon Dec 28, 2017
I wouldn't mind fast-tracking this work by giving out a commercial contract for it, but you being based in US and me being based in India, makes it near impossible. Is there any other commercial user interested in paying for fixing these issues? Maybe all of us can contribute.
And the very reason I brought this discussion up is because GSoC gives us a unique opportunity where Google funds this development. However, the project maintainer (you, or someone else) would stil need to set aside time to mentor students and merge PRs.
Coming to the specific issues:
I'm not sure what you mean by parameter-level protocols? Any link? I meant PREPARE/EXECUTE. How can one currently do this via the public API?
For the fourth case, why isn't a simple interface where each row is handed off to the user in the form of a map or a
[(colName, byteString)]an options?====
The core question is, would the PG simple project be interested in participating in GSoC/HSoC? If yes, then now is the time to organize and plan.
lpsmith commentedon Dec 28, 2017
Oh, believe me, I understand quite well that this does result in a number of additional complications, some of which I don't understand. But, I don't think these issues are insurmountable. Let's discuss over email. I'll send you an email at your Vacation Labs address soon-ish.
Not that I'm aware of. However, that would be another approach.
IIRC, Haskell actually has not received funding from Google the last few years, and the HSoC has instead been funded by a few individuals and companies. I haven't really been involved, so I don't know what this implies, exactly, or if we are attempting to re-establish ourselves as a GSoC participant.
Err, I meant protocol-level parameters. My bad. The frontend/backend protocol isn't as nicely documented as I would hope, but basically it's where you use
$1,$2, etc inside the SQL string as placeholders for the parameter, and then send each parameter as a (Type Oid, format (text or binary), bytestring (length-delimited)) triple inside a protocol message instead of putting it inside the SQL.See for example,
execParams, which, IIRC (I may be slightly incorrect), basically sends aParsemessage followed immediately by aBindmessage in one round-trip, (possibly a single packet?), without waiting for a response to the originalParsebefore sending theBind.One of the big advantages here is that you can use binary formats, which is a big win for some types such as integers, floating point numbers, and timestamps.
So there's a protocol-level notion of statement preparation that differs from the statement-level statement preparation via
PREPAREandEXECUTE. I'm not clear on all the differences, but I'm guessing they are more-or-less the same underlying mechanism, possibly (probably?) with a different namespace.You
executeaPREPAREstatement, then you eitherexecuteorqueryanEXECUTEstatement.This is vaguely similar to what
mysql-simpledoes, and what very early versions ofpostgresql-simple(before 0.1) does as well. The current interface was suggested by Ozgun Ataman, and I liked it enough that I based the whole implementation around it and evolved the interface a bit to avoid creating intermediate data structures that need to be allocated.It sounds like what you really want, is column-name-based parsing instead of positional parsing. I can definitely understand this desire. My main concern is how column-name parsing would interact with positional parsing.
===
Quite possibly.
[-]Haskell Summer of Code 2017?[/-][+]Haskell Summer of Code 2018?[/+]saurabhnanda commentedon Jan 2, 2018
I assume that the Haskell.org committee will attempt getting Haskell included in GSoC this year. Do you want me to formally check with a committee member, or is this a reasonable assumption?
I would vote for this if this were on the table.
This is technically correct. I would've wanted to provide a nicer Haskell-level API for PREPARE/EXECUTE with some type-safety on top of the raw SQL API.
This could be the first goal for interested students - to come up with various ideas for the resulting API and collecting feedback before jumping into implementation.
If that's a firm "yes", then we will need to start acting now! Here's the timeline - https://summerofcode.withgoogle.com/how-it-works/#timeline Applications for organizations are open from 4-23rd Jan.
saurabhnanda commentedon Jan 2, 2018
Btw, from https://summer.haskell.org/
saurabhnanda commentedon Jan 12, 2018
Reminder.
lpsmith commentedon Jan 12, 2018
I don't know if I have enough enthusiasm about this project in order to take it on myself, but I am certainly interested. If you'd like to take the initiative on this, I will do my best to participate. However, I have a lot of other issues to deal with at the moment...