Move `PG` to separate module or contrib

[paluh]

@akheron I've done some simple code separation on simple-core branch.

I'm thinking about two possible approaches to PG monad developement which we should clarify before the next release:

• We can keep it here but add a note in the docs that it is a bit experimental feature and that we need some real live scenarios to stabilize its API.

• We can extract this monad into separate project and experiment there freely. Additionally we can point directly to this new project from this project README.

To be honest I prefer the first option a bit but I'm not sure if this approach is acceptable for our core library ;-)

What do you think?

[akheron]

Going for Aff (Either PGError a) seems like the best option for interoperability with monad stacks. I think this question concerns those users who don't have a custom stack already. It boils down to whether we should give our own stack (the Database.PostgreSQL.PG module) or mere helper functions and examples on how to create your own stack.

[paluh]

Going for Aff (Either PGError a) seems like the best option for interoperability with monad stacks. I think this question concerns those users who don't have a custom stack already.

I've added PG.hoist and PG.hoistWith helpers so even if a user have a custom moand stack it is quite usual to put ExceptT as the last layer of such a stack and it can reuse some parts of existing PG functionality just by hoisting to app stack.

It boils down to whether we should give our own stack (the Database.PostgreSQL.PG module) or mere helper functions and examples on how to create your own stack.

So, I think we are going to provide our stack as a starter.

Do you agree with code organization which you can find on the branch?

• Database.PostgreSQL.PG contains PG related code.
• Database.PostgreSQL contains core functoins and types (based on Either PGError a).

[akheron]

Yes, this sounds good!