On Thu, Sep 03, 2026 at 09:00:26PM -0400, Tom Lane wrote: > Noah Misch <[email protected]> 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.
