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