SQL Server: the schema is created owned by the core schema's owner. SQL Server's
ownership chaining skips the permission check on an object a view references only when both
have the same owner, and an object's owner is its schema's owner. A plain CREATE SCHEMA
makes the INSTALLING login the owner, so an app view reading __mj.Task breaks the chain and
the API login is asked for SELECT on __mj.Task itself (MJ#4756). Creating the schema
AUTHORIZATION <core owner> (usually dbo) keeps the chain intact, so granting the app view
is enough. If the installer may not assign that owner (or could not grant on the objects its
migrations create once it no longer owns them), the schema is still created (install
must not fail on it) and a SchemaOperationResult.Warning names the consequence and the
remedy.
PostgreSQL is untouched: it has no ownership chaining through schemas — a view checks its
base tables' privileges as the VIEW's owner, not the schema's — so the owner of the schema
changes nothing there.
Creates a new database schema for an Open App.
SQL Server: the schema is created owned by the core schema's owner. SQL Server's ownership chaining skips the permission check on an object a view references only when both have the same owner, and an object's owner is its schema's owner. A plain
CREATE SCHEMAmakes the INSTALLING login the owner, so an app view reading__mj.Taskbreaks the chain and the API login is asked for SELECT on__mj.Taskitself (MJ#4756). Creating the schemaAUTHORIZATION <core owner>(usuallydbo) keeps the chain intact, so granting the app view is enough. If the installer may not assign that owner (or could not grant on the objects its migrations create once it no longer owns them), the schema is still created (install must not fail on it) and a SchemaOperationResult.Warning names the consequence and the remedy.PostgreSQL is untouched: it has no ownership chaining through schemas — a view checks its base tables' privileges as the VIEW's owner, not the schema's — so the owner of the schema changes nothing there.