Re: CREATE SCHEMA ... CREATE DOMAIN support

On Thu, Sep 03, 2026 at 09:00:26PM -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > 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.
>
> This is not about that, it is about a9c350d's specific intent "Don't
> try to re-order the subcommands of CREATE SCHEMA". That is, we
> rejected the idea of allowing forward references between CREATE SCHEMA
> subcommands, therefore myview will not bind to a CREATE TABLE
> subcommand that comes after it. Frankly, I don't care about arguments
> that this is not what the spec says: I think this behavior is more
> useful, more intelligible, and less bug-prone than the spec's
> semantics. Moreover we were never going to be able to do what the spec
> says, as discussed in the thread leading up to that commit.

I'm not saying that I want the server to reorder the commands or that I know
of a standard requiring reorder. I'm fine requiring the user to order things
for us. The syntax rule I cited[1] appears to require my original example to
have the same name resolution as this variant w/ more schema qualifications:

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

That succeeds in v18 and fails in v19, which is fine. The problem is that my
original example (with less schema qualification) succeeds in both versions
with different meaning, and the v19 meaning is not standard-compliant.

[1] "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."

> >> +### 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.
>
> Hmm, that one seems like a genuine bug to me; why do you think it
> shouldn't be acted on?

It's genuine, but the combination involved is rare enough that I'd shelve it
so long as we're not in a post-scarcity world. No objection if someone wants
to pursue it.