In getting started it does give the table names... which are all prefixed cd.tablename, it is an educational tool so one would expect one to read the getting started pages first.
>But schemas are a YAGNI 99% of the time feature in those.
What? I literally have only ever written one web app that didn't use multiple schemas, and that was a simple blog. I think you are confusing "I don't bother to use X" with "X isn't very useful".
I don't think it's just about collisions, in fairness. There's also the aspect of managing user permissions by schema, searching for tables, and so on.
Obviously this only becomes super-useful in pretty sizeable projects, but I tend to consider using schemas a good habit to be in.
Have you ever tried using them before? You can set your search path, you don't need to type out schema.table. Your objects are already in a schema anyways, it isn't like you type out public.table all the time. What are these "lots of downsides" you leave unspecified? And how do they outweigh the benefits of grouping database objects together for both namespacing and permissions purposes?
> it is an educational tool so one would expect one to read the getting started pages first
This is the opposite of how it should be. You'd expect learners to be less likely to read a "getting started" page than an expert.
For example, saying to a beginner, "Oh, the tables are all prefixed with cd.tablename" will likely result in a look of confusion because the beginner didn't understand any of the words you used or the way in which you combined them. Is that period special, for example? You said prefix, so if I type "cd.tablenamefacilities" will that work? What are tables and how do I know what their "name" is? Why is the error message talking about "relations?" And so on.
