fix(types): fix enum tables when used in custom mutations #680
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.
Description
@brendanmckenzie reported graphile/crystal#1365 pointing out there's an issue when types that reference enum types are used in custom mutations. This is because we explicitly cast the type of each column, and when we were casting the enum to it's fake name it happened to overlap with the table name, so PostgreSQL thought it was a table reference. Really it should have been a cast to
::text
or whatever type the enum column is.For now I've solved this by casting to
::unknown
if the type is fake; but we should solve it better in the long run by having thePgType
have asqlFullyQualifiedTypeName
field that we can override for fake types to be the type of the column on the enum (e.g.pg_catalog.text
).Fixes graphile/crystal#1365
Performance impact
Negligible.
Security impact
Fixes a bug.