To better support enums in the frontend, we need some more information in the /schema API, here is an example, this column (Field.usage) is an enum but we have no way of telling it from, say, a custom domain type or custom types from extensions. Eventually, we want to make all types editable from the UI. So, we need the /schema API to return that this is an enum and its possible values for enum's case. This will allow us to build features like dropdown select for enum and/or client side validation for enum value.
We can add "checkConstraint" too, which has the PostgreSQL check, e.g. {"checkConstraint": {"length(xata_id) < 256"}}. The frontend can then potentially parse this into a TypeScript validation rule.
Knowing that a type is array, composite, range and their dimensions. Currently, we interpret this in the frontend with some lazy parsing, pgroll should be the source of truth for this information.
To better support enums in the frontend, we need some more information in the
/schema
API, here is an example, this column (Field.usage
) is an enum but we have no way of telling it from, say, a custom domain type or custom types from extensions. Eventually, we want to make all types editable from the UI. So, we need the/schema
API to return that this is an enum and its possible values for enum's case. This will allow us to build features like dropdown select for enum and/or client side validation for enum value.Current output:
Potential future output
Other considerations (very hand-wavey)
{"checkConstraint": {"length(xata_id) < 256"}}
. The frontend can then potentially parse this into a TypeScript validation rule.pgroll
should be the source of truth for this information.postgresType
can be 'enum' | 'array' | 'range' | 'composite' | 'domain' | 'custom-type'For the purpose of this ticket,
enum
is enough.Related https://github.com/xataio/pgroll/issues/376