Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1utYU7-009mMt-6V for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Sep 2025 21:24:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1utYU6-005huL-Bb for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Sep 2025 21:24:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1utYU6-005huB-2I for pgsql-hackers@lists.postgresql.org; Tue, 02 Sep 2025 21:24:10 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1utYU2-000EeR-2l for pgsql-hackers@lists.postgresql.org; Tue, 02 Sep 2025 21:24:10 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 582LO1AO685423; Tue, 2 Sep 2025 17:24:01 -0400 From: Tom Lane To: jian he cc: Kirill Reshke , Peter Eisentraut , PostgreSQL Hackers Subject: Re: CREATE SCHEMA ... CREATE DOMAIN support In-reply-to: References: <1898722.1732732780@sss.pgh.pa.us> <2007224.1732773174@sss.pgh.pa.us> <1075425.1732993688@sss.pgh.pa.us> <345c20e5-a6d7-477a-9598-982661bb5740@eisentraut.org> <1990479.1733256458@sss.pgh.pa.us> <499425.1733936916@sss.pgh.pa.us> Comments: In-reply-to jian he message dated "Tue, 26 Aug 2025 12:53:07 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <685421.1756848241.1@sss.pgh.pa.us> Date: Tue, 02 Sep 2025 17:24:01 -0400 Message-ID: <685422.1756848241@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk jian he writes: > Please check the latest attached. > v7-0001-Don-t-try-to-re-order-the-subcommands-of-CREATE-SCHEMA.patch > v7-0002-CREATE-SCHEMA-CREATE-DOMAIN.patch > v7-0003-CREATE-SCHEMA-CREATE-COLLATION.patch > v7-0004-CREATE-SCHEMA-CREATE-TYPE.patch 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. #2 gives us at least pro-forma spec compliance, and AFAICS it does not introduce any command re-ordering bugs. Foreign key clauses don't depend on each other, so shoving them to the end without any further sorting should be fine. Also ... we don't really have to do #2 until someone complains about the lack of ability to do forward references, which going by history is probably not going to be soon. I certainly don't feel that it has to be completed in this patchset. regards, tom lane