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
somethinglike:
 
   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
tothe   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
tothe new dependency   tracking, the implicit composite type would go away if the function   is dropped.
 


Comments, objections, or thoughts?

Thanks,

Joe