Am 26.07.2011 um 00:40 schrieb Florian Pflug:

> On Jul25, 2011, at 22:31 , Achim Domma wrote:
>> Am 25.07.2011 um 14:48 schrieb Florian Pflug:
>>> A more low-level API is provided by {heap,index}_{beginscan,endscan}, 
>>> heap_{insert,update,delete} and index_insert. However, correct handling of 
>>> transactions using this API isn't easy - for example, to update a row you'd 
>>> first have to find the latest version of that row, then decide if you're 
>>> allowed to update it, and finally create a new version.
>> 
>> I see the problems with the second approach, but that's definitively what I 
>> would like to do.
> 
> You're in for a lot of work, then. I still suggest that you explain your 
> ultimate goals before you embark on your endeavor - people might be able to 
> point our easier ways to achieve those.

I have tables which store two integer IDs and a floating point rank. So the 
table MyTable might have these columns:

EntityID -> int
PropertyID -> int
Rank -> float

My algorithm needs to retrieve EntityID-Rank-Pairs for some given PropertyIDs. 
So I basically want to execute a "select EntityID, Rank from MyTable where 
PropertyID=123 oder by Rank desc". But I need to execute multiple of those 
statements and I don't want to load all the data into memory, but rather 
iterate over the results step by step, stopping at certain thresholds.

My algorithm is somewhat nested and contains logic which I cannot express in 
SQL, but retrieving those pairs is the most basic operation I would need. Are 
cursors and option too? Is there a limitation for the number of open cursors? 
One call might open 100 cursors or so.

cheers,
Achim
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to