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
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 |