Re: holdable cursors - Mailing list pgsql-patches
From | Bruce Momjian |
---|---|
Subject | Re: holdable cursors |
Date | |
Msg-id | 200303271651.h2RGp5R29920@candle.pha.pa.us Whole thread Raw |
In response to | holdable cursors (Neil Conway <neilc@samurai.com>) |
List | pgsql-patches |
Patch applied. Thanks. TODO item marked as done, TODO.detail/cursor removed. --------------------------------------------------------------------------- Neil Conway wrote: > This patch implements holdable cursors, following the proposal > (materialization into a tuple store) discussed on pgsql-hackers earlier. > I've updated the documentation and the regression tests. > > Notes on the implementation: > > - I needed to change the tuple store API slightly -- it assumes that it > won't be used to hold data across transaction boundaries, so the temp > files that it uses for on-disk storage are automatically reclaimed at > end-of-transaction. I added a flag to tuplestore_begin_heap() to control > this behavior. Is changing the tuple store API in this fashion OK? > > - in order to store executor results in a tuple store, I added a new > CommandDest. This works well for the most part, with one exception: the > current DestFunction API doesn't provide enough information to allow the > Executor to store results into an arbitrary tuple store (where the > particular tuple store to use is chosen by the call site of > ExecutorRun). To workaround this, I've temporarily hacked up a solution > that works, but is not ideal: since the receiveTuple DestFunction is > passed the portal name, we can use that to lookup the Portal data > structure for the cursor and then use that to get at the tuple store the > Portal is using. This unnecessarily ties the Portal code with the > tupleReceiver code, but it works... > > The proper fix for this is probably to change the DestFunction API -- > Tom suggested passing the full QueryDesc to the receiveTuple function. > In that case, callers of ExecutorRun could "subclass" QueryDesc to add > any additional fields that their particular CommandDest needed to get > access to. This approach would work, but I'd like to think about it for > a little bit longer before deciding which route to go. In the mean time, > the code works fine, so I don't think a fix is urgent. > > - (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and > adjusted the behavior of SCROLL in accordance with the discussion on > -hackers. > > - (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml > > Cheers, > > Neil [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
pgsql-patches by date: