Joe Conway <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne wrote:
>> Out of interest - why do SRFs need to have a table or view defined that
>> matches their return type? Why can't you just create the type for the
>> function and set it up as a dependency?
> The only current way to create a composite type (and hence have it for
> the function to reference) is to define a table or view.
> We have discussed the need for a stand-alone composite type, but I think
> Tom favors doing that as part of a larger project, namely changing the
> association of pg_attributes to pg_type instead of pg_class (if I
> understand/remember it correctly).
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
