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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
