Wait until you hear what "cluster" means in Postgres-speak.
https://docs.microsoft.com/en-us/sql/relational-databases/in...
https://www.opsdash.com/blog/postgresql-cluster.html
Note that the "databases" above are logical databases, not database hosts.
A PostgreSQL server can contain multiple databases; they are independent and you can't access data in one database while connected to another (without dblink or something similar)
As far as I know pretty much every database (and the SQL standard) except MySQL has schemas as an explicit database object and calls them that. What MySQL calls "databases" are actually schemas; they're just containers for database objects and you can query across them (and CREATE SCHEMA is an alias for CREATE DATABASE)
EDIT:
There's a fun trick you can do with multiple schemas that illustrate why they are schemas and not just "containers of things"
You have a "data" schema that contains your table definitions; your actual, real data and indices etc. go here. Only privileged users can access this schema directly.
Then you have an "interface" schema, that contains views and functions used by people; they can refer to the data schema, and with some clever view definitions, you can do it such that they can only access the data using the views and functions in your interface schema.
At some point, you could create an "interface_v2" schema that provides better (or more) methods for accessing your data that's backwards incompatible. Old applications can continue using the "interface" schema by setting their schema search path to "interface" (which would be the default), but new applications can "overlay" the schemas by setting their search path to "interface_v2,interface" and opt-in to new functionality. The "structure" of your data is changed simply by opting in to the new schema.
It's pretty rare for people to do this (they understand versioned web APIs better than versioned database APIs), but it's a thing you can do.
Maybe we're already agreed on this, but for clarity my point is that the common notion of a schema is strictly "the shape of the data" and not "a container for the data, the shape of the data, and a bunch of other stuff". I agree that this latter definition is probably shared across many relational databases and not just Postgres.
Yeah, I see what you are saying I just disagree. Most people who know either use, in the context of RDBMSs, know both, and resolve the ambiguity by context. This is fairly normal, it's very common for words to have multiple common definitions.
> Most people who know either use, in the context of RDBMSs, know both, and resolve the ambiguity by context. This is fairly normal, it's very common for words to have multiple common definitions.
The RDBMS domain alone doesn't suffice to resolve the ambiguity because "structure of data" and "container of tables/etc" are both relevant. I would definitely contend that application developers and operators (though perhaps not DBAs) need to talk about "structure of data" a lot more than I need to talk about "container of tables/etc".
No, it's a namespace within a database, not a container for databases; this is not Postgres specific, it is part of the SQL standard and widely used in other implementations.
It's helpful to think of "the database" as the actual physical storage, and the schema is what the db uses to make sense of how to manipulate/query that data. From that perspective, the SQL DDL is scripting language to manipulate those schema objects ("objects" in the OOP sense, "schema objects" has an actual specific meaning in SQL).
Though if we talk about database weirdness, I never liked Oracle DB's insistence that databases and users are the same thing. Glad I haven't used it for well over a decade now :)