Re: Extended queries

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extended queries
Date: 2005-12-15 05:31:32
Message-ID: 9970.1134624692@sss.pgh.pa.us
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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-12-15 05:50:44 Re: 7.3 failure on platypus
Previous Message Tom Lane 2005-12-15 05:20:49 Re: Self-modifying code