You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when a field is nullable and an enum, sqlc always generates a new type with a prefix Null. This Null___ type is a struct that wraps the enum's string alias type and adds a Valid boolean property to represent the NULL state.
sqlc has a setting called emit_pointers_for_null_types which replaces similar nullable wrapper types with pointers instead (NullString -> *string)
This feature request seeks to bring similar functionality to nullable enum fields. Instead of generating a Null___ type for a nullable enum field, it should be a represented by a pointer (NullFooEnum -> *FooEnum)
Questions
If this feature were to be implemented, should it be enabled by the existing emit_pointers_for_null_types config setting? Or should it be a separate setting?
Other notes
I couldn't find an existing issue for this, but there is an open PR #3093 which seemed to be working towards the same goal.
What database engines need to be changed?
No response
What programming language backends need to be changed?
No response
The text was updated successfully, but these errors were encountered:
What do you want to change?
Currently, when a field is nullable and an enum, sqlc always generates a new type with a prefix
Null
. ThisNull___
type is a struct that wraps the enum's string alias type and adds aValid
boolean property to represent theNULL
state.sqlc has a setting called
emit_pointers_for_null_types
which replaces similar nullable wrapper types with pointers instead (NullString
->*string
)This feature request seeks to bring similar functionality to nullable enum fields. Instead of generating a
Null___
type for a nullable enum field, it should be a represented by a pointer (NullFooEnum
->*FooEnum
)Questions
emit_pointers_for_null_types
config setting? Or should it be a separate setting?Other notes
I couldn't find an existing issue for this, but there is an open PR #3093 which seemed to be working towards the same goal.
What database engines need to be changed?
No response
What programming language backends need to be changed?
No response
The text was updated successfully, but these errors were encountered: