Re: Question regarding Sync message and unnamed portal

> On Fri, Jan 25, 2013 at 03:24:27PM -0500, Robert Haas wrote:
>> On Fri, Jan 25, 2013 at 2:33 PM, Bruce Momjian <bruce@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 <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 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.
> 
> Yes, I am confused too.  Unless someone replies, we can consider this
> closed.

Sorry for confusion.

I knew an unamed portal only lasts until current transaction ends.  I
was confused in the case when no explicit transaction is used.
 At completion of each series of extended-query messages, the frontend should issue a Sync message.

This is not actually true because Sync is not actually mandatory as
Tom pointed out before. We could use a Flush message instead but it's
another story. And next sentence says:
This parameterless message causes the backend to close the current transaction if it's not inside a BEGIN/COMMIT
transactionblock ("close" meaning to commit if no error, or roll back if error).
 

I did not understand this at first because if we are not inside a
BEGIN/COMMIT transaction block, how does Sync close it? In my
understanding each extended query message(parse/bind/execute) starts
an internal transaction and does not close it until Sync issued(and
Sync is mandatory according to the manual). So if we are not in an
explicit transaction we cannot reuse unnamed portal because Sync
closes the transaction, which in turn destroys the unnamed portal.
This gave me a miss understanding that unnamed portal is destroyed
even transaction is not explicitly closed.

It would be nice if something like "unnamed portal will be destroyed
by a Sync message if you are in an explicit transaction" is in our
manual.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp