Skip site navigation (1) Skip section navigation (2)

Re: functions returning records

From: Alex Pilosov <alex(at)pilosoft(dot)com>
To: Hannu Krosing <hannu(at)tm(dot)ee>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: functions returning records
Date: 2001-06-28 00:10:12
Message-ID: Pine.BSO.4.10.10106272009080.7004-100000@spider.pilosoft.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, 28 Jun 2001, Hannu Krosing wrote:

> Tom Lane wrote:
> > 
> > Jan Wieck <JanWieck(at)Yahoo(dot)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 ... ?
Cannot talk about plpgsql, but for c this would be probably implemented
with setjmp and with perl with goto. Probably not very complex.

-alex


In response to

Responses

pgsql-hackers by date

Next:From: Jan WieckDate: 2001-06-28 01:08:38
Subject: Re: functions returning records
Previous:From: Philip WarnerDate: 2001-06-27 23:54:14
Subject: Re: pg_largeobject is a security hole

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group