Re: CREATE SCHEMA ... CREATE DOMAIN support

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: jian he <jian.universality@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-03T18:35:22Z
Lists: pgsql-hackers
I wrote [ many months ago now ]:
>> I think this is still kind of blocked, because it's not clear to me
>> whether we have consensus about it being okay to do 0001.
>> 
>> Re-reading the thread, the only real use-case for re-ordering that
>> anyone proposed is that foreign key references should be able to be
>> forward references to tables created later in the same CREATE SCHEMA.
>> I concede first that this is a somewhat-plausible use-case and
>> second that it is pretty clearly required by spec.  The fact remains
>> however that we have never supported that in two dozen years, and
>> the number of complaints about the omission could be counted without
>> running out of thumbs.  So, how about the following plan of action?
>> 
>> 1. Rip out subcommand re-ordering as currently implemented, and do the
>> subcommands in the given order.
>> 
>> 2. When a CREATE TABLE subcommand includes a FOREIGN KEY clause,
>> transform that clause into ALTER TABLE ADD FOREIGN KEY, and push
>> it to the back of the CREATE SCHEMA's to-do list.

Nobody has complained about this approach since September, so unless
there's a complaint PDQ, I'm going to take silence as consent and
move forward with reviewing/applying Jian's patchset.

			regards, tom lane



Commits

  1. Don't try to re-order the subcommands of CREATE SCHEMA.

  2. Execute foreign key constraints in CREATE SCHEMA at the end.

  3. Support more object types within CREATE SCHEMA.