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