Simplify PG query constraints

[Kamirus]

Change the internal FFI query function in pg-client to return an object instead of an array.
It would allow simpler parsing the output into the result record (e.g. use ReadForeign or codecs)

[Kamirus]

Let's elaborate what needs to be done.

Motivation

selda uses heavy generic programming on type classes and it proves difficult for the user when something does not type check - error messages might not be helpful
(as a workaround it is advised to break down a problematic query into smaller top-level declarations so that type checker might have a better chance for providing a helpful error message)

Improvement

Executing a query for PG backend is complicated for now

• current PG backend uses postgresql-client which accepts typed tuples as input/output of the query
• selda utilises records
• integration code must translate records into typed tuples in order to execute a query and then parse the output tuple back into a record - this translation is performed on the type-level using type classes
• example: user wants to insert/select record { name :: String, age :: Int, b :: Boolean }, but pg backend accepts tuples of type Int /\ String /\ Boolean

Solutions

• make postgresql-client support records (might be problematic: see this forum topic)
• implement the conversion mentioned above on the value-level and use more primitive API that postgresql-client exposes (e.g. use Array Foreign instead of tuples of types like Int /\ String /\ Boolean)

[paluh]

make postgresql-client support records (might be problematic: see this forum topic)

We can be nearly sure that this won't apply to other backends but real research is needed. Additionally I'm not sure if we want to rely on the js query parsing layer at the end. Given these two issues I think that we shouldn't take this path.

implement the conversion mentioned above on the value-level and use more primitive API that postgresql-client exposes (e.g. use Array Foreign instead of tuples of types like Int /\ String /\ Boolean)

If this transition from nested tuples to untyped arrays is going to simplify selda db interaction then I'm all for it. I'm just not sure if it won't cause some code duplication because you still have to parse ordered tuples but from untyped form like we do in the postgersql-client. We won't probably know if we don't try :-)