Re: Question regarding Sync message and unnamed portal - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Question regarding Sync message and unnamed portal
Date
Msg-id 20130125193344.GK6848@momjian.us
Whole thread Raw
In response to Re: Question regarding Sync message and unnamed portal  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Question regarding Sync message and unnamed portal
Re: Question regarding Sync message and unnamed portal
List pgsql-hackers
On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > On Mon, Oct  1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote:
> >> > Tatsuo Ishii <ishii@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
specifyingthe unnamed portal as destination is issued.  (Note
 

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: autovacuum not prioritising for-wraparound tables
Next
From: Bruce Momjian
Date:
Subject: Re: setting per-database/role parameters checks them against wrong context