Skip site navigation (1) Skip section navigation (2)

Re: patch to create system view that lists cursors

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-patches(at)postgresql(dot)org
Subject: Re: patch to create system view that lists cursors
Date: 2006-01-15 22:57:50
Message-ID: 1137365870.9145.60.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Thu, 2006-01-12 at 19:51 -0500, Tom Lane wrote: 
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > It would also mean that this would produce unexpected results:
> > "PREPARE foo AS SELECT * FROM pg_cursors; EXECUTE foo".
> Unexpected in what sense?

"Unexpected" in the sense that the user would have no reason to expect
an "<unnamed portal n>" row in the pg_cursors view, merely because we
happen to create a portal internally to implement the EXECUTE command.

I think the view should include the portals created by DECLARE CURSOR
and "Bind" protocol messages, but should not include the unnamed portal
or any other portals that are created internally as part of the
implementation of other commands (e.g. EXECUTE). I'm not sure how to
handle SPI: developers using SPI would expect to find their portals in
the view, but those using SPI indirectly (e.g. via PL/foo) would
probably find the clutter surprising. I'd say we need to include SPI
portals in the view as well.


In response to


pgsql-patches by date

Next:From: Andrew DunstanDate: 2006-01-15 23:02:30
Subject: Re: pgxs/windows
Previous:From: Tom LaneDate: 2006-01-15 22:33:06
Subject: Re: inferred param types for PREPARE

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group