Re: functions returning records

Tom Lane wrote:
> 
> 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. 

I dont think that sequence is any more table-like than record.

And difference between type and class ia also quite debatable in 
most languages ;)

Also there seems to be more existing creative use of pg_class - what 
does relkind='s' record for pg_variable stand for ?

> 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.

How hard would it be to turn this around and implement RETURN AND
CONTINUE
for at least PL/PGSQL, and possibly C/Perl/Python ... ?

---------------
Hannu