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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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?
Jan
--
#======================================================================#
# 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 @yahoo.com address at http://mail.yahoo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Vince Vielhaber | 2001-04-26 14:00:42 | Re: [GENERAL] Re: Hardcopy docs available |
Previous Message | mlw | 2001-04-26 12:39:25 | scaling multiple connections |