Re: Question regarding Sync message and unnamed portal

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tatsuo Ishii <ishii(at)postgresql(dot)org>, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Question regarding Sync message and unnamed portal
Date: 2013-01-25 19:33:44
Message-ID: 20130125193344.GK6848@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)us> wrote:
> > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote:
> >> > Tatsuo Ishii <ishii(at)postgresql(dot)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

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-01-25 19:44:25 Re: setting per-database/role parameters checks them against wrong context
Previous Message Robert Haas 2013-01-25 19:22:50 Re: autovacuum not prioritising for-wraparound tables