> Is it necessary to take a base field? Can we not determine the output
field type for some kinds of expression? e.g. F("some_integer_field") + 1
can be assumed to have output field type IntegerField.
It should be possible by simply accessing the `output_field` property of the provided expression once it's resolved yes.
# Will crash as the output field of some_integer_field has not been resolved.
(F("some_integer_field") + 1).output_field
# Will work as F resolved to a Col pointing at SomeModel.some_integer_field (assuming it exists)
(F("some_integer_field") + 1).resolve_expression(Query(SomeModel), allow_joins=False).output_field
But as Paolo demonstrate in his example I think we might want a distinct separation between the column type and the expression used to generate the value of this field if unless we want to force users to do gymnastics to rely on type coercion.
For example, in the reported case the user would have to do `GeneratedField(SearchVector('title'))` which would actually result in `tsvector GENERATED ALWAYS AS to_tsvector(title)` STORED which is not exactly the same. It's not an issue here but I wouldn't be surprised that not being able to configured a generated field to generate a particular SQL output might be problematic in some cases.
What about we make the expected signature `GeneratedField(expression, base_field=None)` where a missing `base_field` defaults to `expression.output_field`? That would allow the exact expected SQL to be generated with `GeneratedField('title', base_field=SearchVectorField())` if there's a requirement for it.