Re: MOVE in SQL vs PLPGSQL

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Richard Huxton <dev(at)archonet(dot)com>, andrew(at)pillette(dot)com, pgsql-sql(at)postgresql(dot)org
Subject: Re: MOVE in SQL vs PLPGSQL
Date: 2005-10-06 20:39:11
Message-ID: 87u0fu5qj4.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Richard Huxton <dev(at)archonet(dot)com> writes:
> > Ah, now I see what you're saying. You're quite right in your suspicions,
> > "MOVE..." isn't supported for plpgsql cursors. You could probably do
> > something with EXECUTE and returning a refcursor from a previous
> > function, but that sounds fiddly.
>
> > I must admit, on the odd occasion I want to skip a row, I just FETCH it
> > and move on. Anyone else?
>
> There is something on the TODO list about improving plpgsql's cursor
> functionality --- there's no reason it shouldn't have MOVE, except that
> no one got around to it yet.

Though the original poster should realize, a MOVE command would be only
marginally more efficient than just fetching those records. It would save the
network overhead and context switches involved in communicating those records,
but there's no way it would let the server avoid reading all those records
from disk.

At least as far as I can see.

--
greg

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Bath, David 2005-10-07 01:07:37 RULES on SELECT with JDBC/perlDBI from other RDBMS products?
Previous Message Frank Bax 2005-10-06 20:28:45 Re: Selecting records not present in related tables