Leon P Smith

Hmm, well it's not exactly ideal if you want to access fields by name either. But otherwise, you do make a lot of good points. The issues with the current...

Also, if all you want to do is a straightforward dump of a query to CSV, the `Copy` module can do this, probably with less code than generating the CSV...

Yes, I hope to issue a major revision sometime, but I don't yet know how to tweak the interfaces yet to solve the various issues, so I really have no...

Actually, come to think of it, there is a way to efficiently get the column names of a table without dropping down to libpq. It's a little hacky, and not...

Another possibility, which is also hacky but _should_ work. I haven't verified it though. First, issue your query with an extra `WHERE FALSE` clause. You could even write `(select *...

Ahh, good point. The `LibPQ.Result` structure should still have all the column names in it, but there isn't any good way at getting at them from postgresql-simple without again mucking...

There's only minimal support for record types in postgresql-simple proper at the moment; namely see the typeinfo module. And I'm not sure if adding an `instance FromField (Integer, Text)` is...

Unless I'm missing something, it looks like postgresql is relatively untyped in this regard. The type is a `_record` which doesn't appear to report the substructure at all: ``` {-#...

Well, there are some other corner cases in the typeinfo system that perhaps aren't handled correctly either. Here's a query that lists types that need to be considered a bit...

Ok, again, the parsing issues should be doable, even if the easiest solution given the current interfaces would not be as efficient as I'd like. And as far as I...