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
