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

Re: first cut at PL/PgSQL table functions

From: Joe Conway <mail(at)joeconway(dot)com>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>,PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: first cut at PL/PgSQL table functions
Date: 2002-08-20 16:13:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Jan Wieck wrote:
> A PL/pgSQL function might (in the future) want to return a refcursor on
> one call, but use RETURN ... AND RESUME on another. So this has to be
> done for every SET. 

How? They are going to be two different datatypes.

> My original idea was to make a tuplestore part of the cursor (Portal
> structure). This way the tuplestore access would be hidden behind the
> fetching and the caller doesn't have to care what the function really
> returns. Also it'd avoid the memory context problem, because the
> tuplestore would be part of the Portal memory context and go away when
> the cursor is closed.

I don't understand your concern. In the current implementation, table 
functions really have very little to do with portals. That was why 
pretty early on (7 May) Tom asked me to "s/portal/function/ throughout 
the patch".

In any case, what Neil has proposed does hide the tuplestore behind the
fetching. The user only declares the tuple return type like they would 
have to anyway. If you're referring to the functionmode being added to 
the grammar, I think Tom has talked us out of that already ;-)


In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2002-08-20 16:38:00
Subject: Re: Correct regression tests
Previous:From: Tom LaneDate: 2002-08-20 16:07:34
Subject: Re: first cut at PL/PgSQL table functions

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