Matthew Wraith

> > Then even if it compiles, there's no guarantee that it'll work. > > I'm not sure I understand. It compiled from master and runs, but you're not sure...

> This is just my opinion, but I really think installing HLS from source should be a good option and be made as easy as possible. This doesn't scale well....

The commit comment says: > This allows to have unions as keys, which often happens when encoding variants made out of nullary constructors. It sounds like string keys shouldn't ever...

Yeah, that was my first thought, but I guess I thought that explicitly making tuples would be more type-safe. Opaleye could just throw an error or something if the list...

Cool. Do you have any thoughts on how to make the `FromField` instances for composite types? Or is there another approach? Right now, my code has a bunch of custom...

One of my actual use-cases is more like this (names are changed, but structurally similar to what I'm doing): ``` sql CREATE TYPE atype AS ENUM ( 'a', 'b' );...

Yeah, so what's weird is that composite types use `FromRow` in `postgresql-simple`. You can nest a `FromRow` in another `FromRow` instance to get a composite type out. Opaleye only uses...

So, all fields in a composite type are _not_ nullable, but whether the composite type is nullable is up to the table. ``` sql CREATE TABLE points (p point NOT...

``` haskell data QueryRunnerColumn pgType haskellType = QueryRunnerColumn (U.Unpackspec (Column pgType) ()) (FieldParser haskellType) ``` `FieldParser` is built into the column query type. Perhaps it needs to be either FieldParser...

I'm setting up a test with this. Maybe it's way off, but it's a thought. This will break for nullable fields with a row-type (because of the implementation of `queryRunnerColumnNullable`)....