| From: | Ian Lance Taylor <ian(at)airs(dot)com> | 
|---|---|
| To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Cursor support in pl/pg | 
| Date: | 2001-04-26 06:43:41 | 
| Message-ID: | siitjscg9u.fsf@daffy.airs.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
>     IIRC  the  patch  only  provides  the  syntax  for  CURSOR to
>     PL/pgSQL. Not real cursor support on the SPI level.  So  it's
>     still the same as before, the backend will try to suck up the
>     entire resultset into the SPI tuple table (that's memory) and
>     die if it's huge enough.
> 
>     What  we  really need is an improvement to the SPI manager to
>     support cursor (or cursor  like  behaviour  through  repeated
>     executor calls).
Agreed, but as I may have said before, 1) the problem you describe
already exists in PL/pgSQL when using the FOR x IN SELECT statement,
2) the PL/pgSQL cursor patch is useful without the improvement to the
SPI layer, 3) I would argue that the PL/pgSQL cursor patch is still
needed after the SPI layer is improved.
So I do not think that is a valid argument against installing the
PL/pgSQL cursor patch.
Ian
---------------------------(end of broadcast)---------------------------
TIP 83: The only thing cheaper than hardware is talk.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jean-Michel POURE | 2001-04-26 08:36:20 | Important news about PgAdmin >>>> Drop/create functions, triggers and views and relink the whole system without restarting PostgreSQL | 
| Previous Message | mlw | 2001-04-26 01:34:38 | Open source is great, but too tempting |