We should introduce a new annotation that can be defined on Catalog, schema, or table to change the behavior of columns.
The following is how this annotation would look like. This allows defining all column level annotations on upper levels by just specifying their types or names.
This will satisfy both #939 and #877. We can use the by_name property to change the display settings of system columns, and by_type would allow changing the format of all timestamp columns.
The following is an example of using this annotation:
by_type should match exactly with the typename of the column. So, for example, for array columns, we would have to use "boolean[]".
While determining annotations for a column, the more specific one will be used. So by_name has more priority over by_type, and the annotations defined on the column itself have the highest priority.
While by_name doesn't really make sense on tables, the by_type could be useful on a table. That's why we're going to allow this annotation on tables as well.
We should introduce a new annotation that can be defined on Catalog, schema, or table to change the behavior of columns.
The following is how this annotation would look like. This allows defining all column level annotations on upper levels by just specifying their types or names.
This will satisfy both #939 and #877. We can use the
by_name
property to change the display settings of system columns, andby_type
would allow changing the format of all timestamp columns.The following is an example of using this annotation:
by_type
should match exactly with thetypename
of the column. So, for example, for array columns, we would have to use"boolean[]"
.by_name
has more priority overby_type
, and the annotations defined on the column itself have the highest priority.by_name
doesn't really make sense on tables, theby_type
could be useful on a table. That's why we're going to allow this annotation on tables as well.