From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | ishii(at)sraoss(dot)co(dot)jp, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Extended queries |
Date: | 2005-12-15 06:27:13 |
Message-ID: | 20051215.152713.41628707.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> writes:
> > However a extended query "Execute" does not return CommandComplete
> > (note: ErrorResponse will be returned if an error occurs). Although
> > the doc says " Therefore, an Execute phase is always terminated by the
> > appearance of exactly one of these messages: CommandComplete,
> > EmptyQueryResponse (if the portal was created from an empty query
> > string), ErrorResponse, or PortalSuspended", I don't think the
> > description is quite correct from observing the actual implementation
> > (or the implementation is wrong).
>
> If you can demonstrate that this is not so, I'd like to see it.
>
> > A workaround I found so far was issuing "Flush" immediately after
> > "Execute".
>
> This seems to indicate that you may be confused about the difference
> between "backend responds with message xyz" and "message xyz will be
> immediately delivered to the client". In *all* cases, you should send
> either Flush or Sync before waiting for a backend response, because
> only those message types force the backend output buffer to be flushed.
My point is, message xyz is immediately delivered or not is not very
cleary described in the docs.
For example in "simple" quries at the completion of the commands
CommandComplete is immediately delivered despite it's not cleary
stated in the docs.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-15 06:37:03 | Re: Extended queries |
Previous Message | Tom Lane | 2005-12-15 05:50:44 | Re: 7.3 failure on platypus |