public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: jian he <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: CREATE SCHEMA ... CREATE DOMAIN support
Date: Tue, 02 Sep 2025 17:24:01 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CACJufxGOtXuJD3VLOMUQr08Zt3=8HjH0KYk2NivYPuMbHG2JQg@mail.gmail.com>
References: <CALdSSPh4jUSDsWu3K58hjO60wnTRR0DuO4CKRcwa8EVuOSfXxg@mail.gmail.com>
<CACJufxG+mrh2O9RS0gX43gU6sv+CMY847eMjMQpe8t4ou-2ryg@mail.gmail.com>
<CACJufxFUdgqDiK9B+VNtnAwZOj=O3NqdLtXO_OrOwE5XPdCpBA@mail.gmail.com>
<CALdSSPggNNvcad69dhUceZ_gPuEYnKNNd=WJ_WnP=YDmh=iwmw@mail.gmail.com>
<[email protected]>
<CALdSSPhckRXW+KEvdsUmkQ-ErbrP_vPNjGwgXNdpXDb8xnLEbQ@mail.gmail.com>
<[email protected]>
<CALdSSPgftbtV=UyeK_XcLit_mKQZr+g8pCxA0kLLxDi0kKwEGw@mail.gmail.com>
<CACJufxH5TvkQiMOJ9dpDrDbRtyCa-yu+QOmYGt4WGGYVrN+P8g@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CALdSSPi1eFMhAY6Xc7ZShnU0m5YrswOFLyDKrFzLjYd7wefzQg@mail.gmail.com>
<[email protected]>
<CACJufxF28Vk27JhJ9u8tq10BoHLg=T9=wJ8zqTy_ajM4=Czunw@mail.gmail.com>
<CALdSSPjH3Ag_6v=Q+mnhJocaYor0eGYOYkZWDG8w2rXRVioTXw@mail.gmail.com>
<[email protected]! mail.com>
jian he <[email protected]> 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
view thread (32+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: CREATE SCHEMA ... CREATE DOMAIN support
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox