Re: CREATE SCHEMA ... CREATE DOMAIN support

On Mon, Apr 06, 2026 at 03:19:48PM -0400, Tom Lane wrote:
> I pushed v13 after a tiny bit of additional tweaking.

I had Opus 5 review d516974 "Support more object types within CREATE SCHEMA".
It raised a problem in a9c350d "Don't try to re-order the subcommands of
CREATE SCHEMA":

> +## 4. Findings that belong to the sibling commit a9c350d, not to d516974

> +The common cause: `a9c350d` deleted `setSchemaName()`, which used to write the new schema's
> +name into each element's `RangeVar->schemaname` [...] From then on the new schema
> +reaches its own elements solely through a prepended `search_path` entry

> + [...] ISO/IEC 9075-2 5.4 SR 4)b) (found.txt:8701-8702) reads verbatim
> +"If the <local or schema qualified name> is contained in a <schema definition>, then the
> +<schema name> that is specified or implicit in the <schema definition> is implicit."

The full review, attached, contains several examples. Some are exotic.
Here's one that resonates more with me, adapted slightly from the a9c350d
commit message:

CREATE TABLE public.mytable (c int);
CREATE SCHEMA myschema
CREATE VIEW myview AS SELECT * FROM mytable
CREATE TABLE mytable (c int);
SET search_path = pg_catalog;
\d+ myschema.myview
RESET search_path;

In v18, myview binds to myschema.mytable. In v19, it binds to public.mytable.
I think the above-described syntax rule about <local or schema qualified name>
doesn't allow v19's interpretation.

Stepping back, I am concerned about the complexity v19 is incurring to extend
CREATE SCHEMA ... CREATE. The syntax gives only modest benefits, since you
can achieve the same object creation with freestanding SQL statements. The
above example is indicative of the unusual semantic challenges. CREATE SCHEMA
... CREATE also handicaps the parsing of every command it supports, since
parsing can't rely on semicolons to find command boundaries. I grant this
project closed one gap in PostgreSQL SQL standard compliance. I'm concerned
about painting ourselves into a corner with respect to future syntax needs.

Here are my notes on the d516974 findings in the report, only one of which I
consider a non-negligible bug in d516974.

> +### D1 — psql (and pgbench) do not end a `CREATE SCHEMA` at its semicolon when a `GRANT` clause follows a routine clause

This title overstates the connection to $SUBJECT. As the report goes on to
explain, this is a variant of an older bug of psql detecting "begin" in the
wrong contexts:

-- works
CREATE FUNCTION x1f() RETURNS int LANGUAGE sql SET search_path = "begin" AS 'select 1';
select 'ended';
-- psql wrongly concludes command is not yet terminated
CREATE FUNCTION x1f() RETURNS int LANGUAGE sql SET search_path = begin AS 'select 1';
select 'ended';

This doesn't affect pg_dump, fortunately, which always quotes the GUC value.

> +### D2 — a `SET role` / `SET session_authorization` clause on a routine element is refused under `AUTHORIZATION`, naming a security-definer function that does not exist

I would not act on this.

> +### D3 — PL/pgSQL cannot contain a `CREATE SCHEMA` whose element is a `BEGIN ATOMIC` routine

I think this does qualify as a bug in d516974, but it's not very concerning.

> +### D4 — psql offers `COLLATION` and `TYPE` as `CREATE SCHEMA` clauses but does not complete them

I would not act on this.