Re: Question regarding Sync message and unnamed portal

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Question regarding Sync message and unnamed portal
Дата
Msg-id 20130125193344.GK6848@momjian.us
обсуждение исходный текст
Ответ на Re: Question regarding Sync message and unnamed portal  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Question regarding Sync message and unnamed portal  (Robert Haas <robertmhaas@gmail.com>)
Re: Question regarding Sync message and unnamed portal  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: autovacuum not prioritising for-wraparound tables
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: setting per-database/role parameters checks them against wrong context