Tom Lane wrote: > Well, it's not an optional larger project: there just isn't any way ATM > to define a composite type that's not linked to a pg_class entry. The > only way to show fields of a composite type is through pg_attribute > entries, and pg_attribute entries are bound to pg_class entries not > pg_type entries. > > The clean way to restructure this would be to link pg_attribute entries > to pg_type not pg_class. But that would break approximately every > client that looks at the system catalogs. > > An alternative that just now occurred to me is to invent 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. Not sure of all the > implications, but it might be worth pursuing. >
I was originally thinking the same thing, but I guess I didn't think it would fly. Could we steal the needed parts from CREATE and DROP VIEW, except make a new relkind 'f' and skip the RULEs? Something like: CREATE TYPE typename AS ( column_name data_type [, ... ]) FWIW, you can see an example of Oracle's CREATE TYPE here: http://download-west.oracle.com/otndoc/oracle9i/901_doc/appdev.901/a89856/08_subs.htm#19677 And perhaps we could do: CREATE [ OR REPLACE ] FUNCTION name ( [ argtype [, ...] ] ) RETURNS [setof] { data_type | (column_name data_type [, ... ]) } . . . to automatically create a composite type with a system generated name for a function. Someone reported a similar syntax for InterBase here: http://archives.postgresql.org/pgsql-sql/2002-07/msg00011.php Thoughts? Joe ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
