Why does GoodData map a Postgres smallint to an int but make it an attribute instead of a fact, while in the same dataset it makes a Postgres int into a numeric and sees it as a fact? See the columns 'Weeks rented' and 'Dwelling rce' in the screenshot, which shows how the data was mapped automatically after dragging the table in:

GoodData Cloud treats numeric fields differently depending on their intended use within analytics. When a column like

smallint

(e.g., 'Weeks rented') is mapped as an attribute, it likely indicates that the values in the column are meant to be used for categorization or grouping rather than quantitative analysis. You can always convert it to a fact by following our documentation here: https://www.gooddata.com/docs/cloud/model-data/evolve-your-model/convert-facts-and-attributes/

I'm curious more precisely why this column (and all other smallint types) are being mapped as attributes -- why can't an integer that simply has a smaller max value not be used for quantitative analysis (without having to follow more steps)? Since this is coming from Postgres, the actual values in this column are in fact all numbers... It seems totally arbitrary for GoodData to have this default behavior.

Usually, it is not required to use these numbers to make aggregations, nonetheless, the datatype assigned by the modeler is just a suggestion and you can always covert it to the desired type by following the steps in the documentation.

Yes, but do you see the runaround here -- some features only work well upon doing a fresh new dataset dragged in (ie. timestamps), and other features only work properly if you make corrections after dragging in a new dataset (ie. fixing these strange defaults around smallints, which should be an option that users can configure, BTW). This leads to a a circular game where to get the dataset set up correctly, one may need to start it over from scratch, but doing so then forces you to go and re-apply all these corrections again and again? This does not sound like a great developer experience.

As stated in our internal conversation, I am afraid this is working as expected and I do not have further advise at this time. But if I can gladly submit product feedback on your behalf. Do I understand correctly that you would like numeric columns remain unchanged when adding a table in GoodData Cloud? As explained previously, some columns can be identified as "string" type depending on the context, but you can always convert them afterward.