Re: CREATE SCHEMA ... CREATE DOMAIN support

I wrote:
> 2. transformCreateSchemaStmtElements is of the opinion that it's
> responsible for ordering the schema elements in a way that will work,
> but it just about completely fails at that task. Ordering the objects
> by kind is surely not sufficient, and adding CREATE DOMAIN will make
> that worse. (Example: a domain could be used in a table definition,
> but we also allow domains to be created over tables' composite types.)
> Yet we have no infrastructure that would allow us to discover the real
> dependencies between unparsed DDL commands, nor is it likely that
> anyone will ever undertake building such. I think we ought to nuke
> that concept from orbit and just execute the schema elements in the
> order presented. I looked at several iterations of the SQL standard
> and cannot find any support for the idea that CREATE SCHEMA needs to
> be any smarter than that. I'd also argue that doing anything else is
> a POLA violation. It's especially a POLA violation if the code
> rearranges a valid user-written command order into an invalid order,
> which is inevitable if we stick with the current approach.

Further to this: I don't think "re-order into a safe order" is even
a well-defined requirement. What should happen with

CREATE VIEW public.v1 AS SELECT * FROM foo;

CREATE SCHEMA s1

CREATE VIEW v0 AS SELECT * FROM v1;

CREATE VIEW v1 AS SELECT * FROM bar;

If we re-order the CREATE VIEW subcommands, this means something
different than if we don't. Maybe the user meant us to re-order,
but it's hardly an open-and-shut argument. And historically we
have not re-ordered CREATE VIEW subcommands, so there's a hazard
of compatibility problems if we did ever try to do that.

So attached is a draft patch that simplifies the rule to "do the
subcommands in the order written". I took the opportunity to clean up
some other small infelicities about transformCreateSchemaStmtElements,
too.

regards, tom lane