| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: portal pinning |
| Date: | 2017-12-15 20:36:17 |
| Message-ID: | dda52d44-da5a-bb3a-6870-35b40e76d1bf@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/12/17 10:34, Peter Eisentraut wrote:
> But I also wonder whether we shouldn't automatically pin/unpin portals
> in SPI_cursor_open() and SPI_cursor_close(). This makes sense if you
> consider "pinned" to mean "internally generated". I don't think there
> is a scenario in which user code should directly operate on a portal
> created by SPI.
Here is a patch for this option.
The above sentence was not quite correct. Only unnamed portals should
be pinned automatically. Named portals are of course possible to be
passed around as refcursors for example.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Move-portal-pinning-from-PL-pgSQL-to-SPI.patch | text/plain | 2.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-12-15 20:41:14 | Re: Bug: Ambiguous Column Reference Allowed When Joining to pg_roles.oid |
| Previous Message | Robert Haas | 2017-12-15 20:13:20 | Re: Top-N sorts verses parallelism |