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

Re: Cursor support in pl/pg

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Ian Lance Taylor <ian(at)airs(dot)com>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Cursor support in pl/pg
Date: 2001-04-26 13:48:13
Message-ID: 200104261348.IAA01708@jupiter.jw.home (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Ian Lance Taylor wrote:
> 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.

    I  don't  object if we can be sure that it's implementing the
    syntax a final version with *real* cursor support will  have.
    Can we?



# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #

Do You Yahoo!?
Get your free address at

In response to


pgsql-hackers by date

Next:From: Vince VielhaberDate: 2001-04-26 14:00:42
Subject: Re: [GENERAL] Re: Hardcopy docs available
Previous:From: mlwDate: 2001-04-26 12:39:25
Subject: scaling multiple connections

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