-
Notifications
You must be signed in to change notification settings - Fork 3
Better type inference for insert #47
Copy link
Copy link
Open
Labels
backend-integrationInterop code between DSL and some db backend, e.g. generate SQL, execute, [de]serialize resultsInterop code between DSL and some db backend, e.g. generate SQL, execute, [de]serialize resultserror messageRefers to compilation errors (unclear, misleading, ...)Refers to compilation errors (unclear, misleading, ...)
Description
Activity
Metadata
Metadata
Assignees
Labels
backend-integrationInterop code between DSL and some db backend, e.g. generate SQL, execute, [de]serialize resultsInterop code between DSL and some db backend, e.g. generate SQL, execute, [de]serialize resultserror messageRefers to compilation errors (unclear, misleading, ...)Refers to compilation errors (unclear, misleading, ...)
insert(as well asinsert_) has a meaningless type for a user, thus it is hard to start using it.motivation: #40 has more background on this issue.
Say we have the following table definition:
We should be able to apply
insert_toemployeesand let type inference figure out the rest.But this is not currently the case as
salaryis a default column, thus we can assign two different types toinsert_ employeesPotential Solution
Change (or provide an alternative) insert to allow only one type once a table is provided (type parameter
tshould uniquely determinerfrom the type ofinsert_).Types of optional columns should get wrapped with
Maybe.Then definition
Should be inferred to