Re: CREATE SCHEMA ... CREATE DOMAIN support

Here's a revised patchset that I think is pretty close to committable.
I reorganized it some compared to v11: 0001 is still about the same,
but the business with allowing circular foreign keys is now in 0002,
because it seems like that bears directly on whether we should
consider 0001 acceptable.  And then I squashed all the object-type
additions into 0003, because dealing with them all at once seemed
simpler.

I rewrote 0002 rather heavily, mainly because it assumed it could
scribble on the input query tree which I don't think is okay.
The functionality is still the same though.

I was kind of sad that 0003 didn't support functions/procedures,
because (a) the SQL spec requires those in CREATE SCHEMA, and
(b) they are a flagship feature for Postgres, mainly because they
are such a critical aspect of extendability.  So I added that,
which only required adding CreateFunctionStmt to the set of
supported node types in transformCreateSchemaStmtElements.

I really didn't like the stringify_objtype() business in 0003:
it's messy and there is no guarantee that ObjectTypeMap will map
ObjectType codes the way you want them.  However, we can easily
get rid of that.  It was used for reporting "CREATE <objecttype>"
in error messages, but we don't really need that in the wrong-
schema-name message, as evidenced by the precedent of checkSchemaName
which has always just said "CREATE specifies a schema ...".
And as for the other usage of rejecting subclasses of DefineStmt,
let's just not reject them.  The existing other subclasses are
CREATE AGGREGATE and CREATE OPERATOR, which I think we should
support if we are supporting functions, plus text search objects.
I don't especially care whether CREATE SCHEMA allows CREATE TEXT
SEARCH commands, but I certainly don't see the value of adding
grungy code just to reject them.

While testing this I observed that including new-style SQL
functions/procedures in CREATE SCHEMA failed, because psql's heuristic
for determining when a semicolon ends the command didn't account for
this case.  So 0003 includes a patch for that, but it's even more
heuristic-y than before; I don't know if there are any plausible cases
where it'd misbehave.

psql's tab-complete support could stand to be improved more.
I fixed the CREATE TEXT SEARCH rules to change Matches to TailMatches,
but there are other places such as CREATE COLLATION that I didn't
touch because they have usages of HeadMatches plus TailMatches, and
it's not clear how to make those rules work.  I don't think that's
a commit-blocker, though.

As noted in the draft commit message for 0003, this puts us at
a point where we could reasonably claim to be feature-complete
for CREATE SCHEMA.  We support all the subcommand types required
by the spec, except for object types we don't implement at all
yet, plus CREATE CAST/TRANSFORM/ROLE.  Regarding those three
types of object as belonging to a schema seems problematic
for us, because they don't have schema-qualified names.
So I'm content to draw a line under this and say we're done.
Perhaps we should rewrite create_schema.sgml's Compatibility
section with that in mind, and with less apology for not
supporting command re-ordering.

			regards, tom lane