jian he <jian.universal...@gmail.com> 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
