Proposal: stand-alone composite types

We've discussed at least a couple of times before that it would be nice
to be able to create stand-alone composite types. Tom mentioned that
ideally this would be done as part of a refactoring of system tables so
that attributes belonged to pg_type, instead of belonging to pg_class.
But it wasn't clear that this approach was worth the effort,
particularly due to backwards compatability breakage.

Recently Tom mentioned another alternative (see:
http://archives.postgresql.org/pgsql-hackers/2002-07/msg00788.php for
more). The basic idea was to "create a new 'dummy' relkind for a
pg_class entry that isn't a real relation, but merely a front for a
composite type in pg_type."

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.

3. Modify CREATE FUNCTION to allow the implicit creation of a dependent
composite type, e.g.:

CREATE [ OR REPLACE ] FUNCTION name ( [ argtype [, ...] ] )
RETURNS [setof] { data_type | (column_name data_type [, ... ]) }...

This would automatically create a stand-alone composite type with a
system generated name for the function. Thanks to the new dependency
tracking, the implicit composite type would go away if the function
is dropped.

Comments, objections, or thoughts?

Thanks,

Joe