Re: holdable cursors

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: holdable cursors
Date: 2003-03-25 22:03:15
Message-ID: 200303252203.h2PM3FN03162@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------

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(at)postgresql(dot)org)

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2003-03-25 22:03:23 Re: Doc patch for func.sgml
Previous Message Bruce Momjian 2003-03-25 22:02:20 Re: psql / tab-completion.c : patch proposals