search

lpsmith / postgresql-libpq

Low-level Haskell bindings for libpq
BSD 3-Clause "New" or "Revised" License
19 stars 18 forks source link

Add range type support (9.2 beta) #5

Closed msieradzki closed 12 years ago

msieradzki commented 12 years ago

Range types (http://www.postgresql.org/docs/devel/static/rangetypes.html) are very useful and it'd be nice to have support for them in Haskell binding. As far as I understand we need:

lpsmith commented 12 years ago

Well, nothing needs to be done to postgresql-libpq. The proper location for this issue would be postgresql-simple.

Also, you should be able to add support for range types to postgresql-simple without modifying postgresql-simple itself, though I do intend on eventually supporting range types in the base distribution. All you have to do is declare a datatype to represent the range type (I would not use pairs), and then make FromField and ToField instances for that datatype.

Your third point, basic functions that work on range types, is currently beyond the scope of postgresql-simple, as the current practice is to write your own SQL literals. postgresql-simple currently offers almost no functionality to generate sql queries or make them look like Haskell code.

lpsmith commented 12 years ago

Also, if you are interested on working on this issue, I would encourage you to write your own support for Range types in your own code. (Remember, no modifications to postgresql-simple should be needed, though haven't investigated this issue so I may well be wrong. I'm willing to help you do this.) Then if you come up with something you like, I will consider moving it into postgresql-simple.

lpsmith commented 12 years ago

One more comment, to clarify what postgresql-libpq is, it's a very thin wrapper around libpq only. All it does is provide a Haskell binding to libpq and add automatic memory management. There is no support for any kind of datatypes here; since range types introduce no changes to libpq, there are no changes needed to postgresql-libpq.

msieradzki commented 12 years ago

Yes, I'll probably work on it myself.

When it comes to libpq I thought there might be tiny bit that has to be changed because range types have new Oids though I haven't figured it all out.

lpsmith commented 12 years ago

Nope, libpq just passes the oids through, and doesn't deal with them directly. (Other than locating them and giving something else the ability to ask about the OID).

Regarding OIDs and postgresql-simple, there is a table for stable type oids in the BuiltinTypes module. For types that don't have a stable OID (or aren't in the table), postgresql-simple will retrieve the typname from the metaschema the first time it runs across an unknown type OID. It then sticks that typname into a per-connection cache for future use. This typname can be retrieved using Database.PostgreSQL.Simple.FromField.typename.

You can take a look at the code that handles typnames if you want. It's entirely possible that to do a really good job with Range types, that you may want to retrieve and store some additional information than just the typname, such as the type it ranges over.

lpsmith commented 12 years ago

Also, feel free to open an issue on postgresql-simple, saying that postgresql-simple needs support for range types, so that I have a reminder.

lpsmith commented 11 years ago

Hmm, maybe I misinterpreted your third bullet point. Some basic functions to work with ranges in Haskell-land would be a good idea, and totally within the scope of postgresql-simple.

We need to overhaul the 0.3 typeinfo system to do a good job with range types though. Otherwise you can't write a general instance that supports all range types, you can only write instances that support specific range types.