On Fri, Jan 25, 2013 at 2:33 PM, Bruce Momjian <br...@momjian.us> wrote: > On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote: >> On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian <br...@momjian.us> wrote: >> > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote: >> >> > Tatsuo Ishii <is...@postgresql.org> writes: >> >> >> From the manual: >> >> >> "An unnamed portal is destroyed at the end of the transaction" >> >> > >> >> > Actually, all portals are destroyed at end of transaction (unless >> >> > they're from holdable cursors). Named or not doesn't enter into it. >> >> >> >> We need to fix the document then. >> > >> > I looked into this. The text reads: >> > >> > If successfully created, a named prepared-statement object lasts >> > till >> > the end of the current session, unless explicitly destroyed. An >> > unnamed >> > prepared statement lasts only until the next Parse statement >> > specifying >> > the unnamed statement as destination is issued. >> > >> > While the first statement does say "named", the next sentence says >> > "unnamed", so I am not sure we can make this any clearer. >> >> I'm not sure what this has to do with the previous topic. Aren't a >> prepared statement and a portal two different things? > > Oops, thanks. Here is the right paragraph, same issue: > > If successfully created, a named portal object lasts till the end of the > current transaction, unless explicitly destroyed. An unnamed portal is > destroyed at the end of the transaction, or as soon as the next Bind > statement specifying the unnamed portal as destination is issued. (Note
OK. Well, that seems clear enough. I'm not sure what it has to do with the original complaint, though, because I don't quite understand the original complaint, which seems to involve not only when portals are destroyed but also what effect Sync messages have. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
