Jan Wieck <JanWieck@Yahoo.com> writes:
> 1. Adding a new relkind that means 'record'. So we use
> pg_class, pg_attribute and pg_type as we do for tables
> and views to describe a structure.
It seems fairly ugly to have a pg_class entry for something that
isn't a table or even a table-like entity. It would be nice if
we could describe a record type with only pg_type and pg_attribute
entries. I haven't thought about it in detail, but seems like it
could be done if pg_attribute entries are changed to reference
pg_type, not pg_class, rows as their parent. However, this would
break so many existing queries in psql and other clients that it'd
probably be unacceptable :-(
> 2. A function that RETURNS SETOF record/table/view is
> expected to return a refcursor (which is basically a
> portal name - SPI support already in 7.2), who's tupdesc
> matches the structure.
Otherwise this proposal sounds good. Jan and I talked about it earlier;
one point I recall is that the portal/cursor based approach can
internally support the existing multiple-call implementation of
functions returning sets. That is, when you call the portal to get the
next tuple, it might hand you back a tuple saved from a previous
function call, or it might turn around and call the function again to
get the next tuple.
BTW, once we've had this for a release or two, I'd like to rip out the
existing support for calling functions-returning-sets during SELECT list
evaluation, so that expression evaluation could be simplified and sped
up. But we can wait for people to change over their existing uses
before we do that.
regards, tom lane
