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

Increse safety of parameter subsitution? #241

Open
BardurArantsson opened this issue Dec 25, 2017 · 1 comment
Open

Increse safety of parameter subsitution? #241

BardurArantsson opened this issue Dec 25, 2017 · 1 comment

Comments

@BardurArantsson
Copy link
Contributor

BardurArantsson commented Dec 25, 2017

So, I've been notificing a pattern in some of my own code (and similarly in postgresql-simple code). There seems to be quite a bit of duplication of functions depending on whether or not query substitution is to be performed. For example, in postgresql-simple we have:

query :: (ToRow q, FromRow r) => Connection -> Query -> q -> IO [r]
query_ :: FromRow r => Connection -> Query -> IO [r]

queryWith :: ToRow q => RowParser r -> Connection -> Query -> q -> IO [r]
queryWith_ :: RowParser r -> Connection -> Query -> IO [r]

I was just wondering: Do you know if there's any "deep" reason for this? It seems like it would be a straight up win to have separate data constructors, e.g.

data Query =
      ParameterizedQuery ByteString (exists p . ToRow p => [p])
    | RawQuery ByteString

(I'm not sure the type signature actually works, but the point is that a parameter list only requires a ToRow class. It could perhaps also be split out to decouple if from ToRow, but that's a side issue.)

This is obviously not a huge deal, but it would be nice to avoid the combinatorial "explosion".

Any ideas?

@lpsmith
Copy link
Owner

lpsmith commented Aug 13, 2018

Yes, you have identified one of my dissatisfactions with the current API, but I haven't thought that much about it.

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