Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So this is the draft of possible imlementation of #37.
Recap: The main problem with this issue is that changing the
Column
in read part ofTableProperties
toTableColumn
, that enables having other information in the table than just the column name will possibly break type inference. Excerpt fromSchema.hs
:Here, the
col2
is not specified so the type inference engine don't know which instance to use. So, one needs to provide explicit type signature.Then the
query'
compiles.There are some solution ideas that come to mind:
read
part ofTableProperties
, that would replace all occurences ofTableColumn
withColumn
, that can be then provided to the inferencer. Or do the same thing with macro?Column
s before doing schema operations.Another obvious issue is that the type of table will change and there is one more table type for the user to specify.
T1
&T'
are types provided in theTable
definition.T''
is a type that is used when helping the type inference.Any ideas, how to do this in an elegant way?