stand-alone composite types patch (was [HACKERS] Proposal: stand-alone composite types)

Joe Conway wrote:
> Based on Tom's suggestion, I propose the following:
>
> 1. Define a new pg_class relkind as 'c' for composite. Currently relkind
> can be: 'S' sequence, 'i' index, 'r' relation, 's' special, 't'
> toast, and 'v' view.
>
> 2. Borrow the needed parts from CREATE and DROP VIEW to implement a new
> form of the CREATE TYPE command, with syntax something like:
>
> CREATE TYPE typename AS ( column_name data_type [, ... ] )
>
> This would add a pg_class entry of relkind 'c', and add a new
> pg_type entry of typtype 'c', with typrelid pointing to the
> pg_class entry. Essentially, this new stand-alone composite type
> looks a lot like a view without any rules.

Items 1 and 2 from the proposal above are implemented in the attached
patch. I was able to get rid of the reduce/reduce conflict with Tom's
help (thanks Tom!).

test=# CREATE TYPE compfoo AS (f1 int, f2 int);
CREATE TYPE
test=# CREATE FUNCTION getfoo() RETURNS SETOF compfoo AS 'SELECT fooid,
foosubid FROM foo' LANGUAGE SQL;
CREATE FUNCTION
test=# SELECT * FROM getfoo();
f1 | f2
----+----
1 | 1
1 | 2
(2 rows)

test=# DROP TYPE compfoo;
NOTICE: function getfoo() depends on type compfoo
ERROR: Cannot drop relation compfoo because other objects depend on it
Use DROP ... CASCADE to drop the dependent objects too
test=# DROP TYPE compfoo CASCADE;
NOTICE: Drop cascades to function getfoo()
DROP TYPE

Passes all regression tests (well, I'm on RedHat 7.3, so there are three
"expected" failures). Doc and regression adjustments included. If there
are no objections, please apply.

Thanks,

Joe