Makes sense, thanks!
On Thu, Jul 2, 2020 at 15:29 Tom Lane wrote:
> =?UTF-8?B?SmFrYSBKYW7EjWFy?= writes:
> > What is a common situation for using Flush instead of Sync?
> > When would you need and wait for the output, get an error, yet still
> > proceed to send further messages that you would w
=?UTF-8?B?SmFrYSBKYW7EjWFy?= writes:
> What is a common situation for using Flush instead of Sync?
> When would you need and wait for the output, get an error, yet still
> proceed to send further messages that you would want the server to ignore?
The only case I can think of offhand is bursting s
Hehe, that's exactly what I am doing, which is why I thought of just
sending two Syncs. Good to hear it's OK.
>From reading the Extended query protocol docs, I somehow got the impression
that you need to do everything within one cycle, and send Sync only at the
end of the cycle:
- "The extended
=?UTF-8?B?SmFrYSBKYW7EjWFy?= writes:
> For an extended query that needs to get parameter types before sending
> them, is there a difference in doing:
> Parse, Describe statement, Flush, Bind, Execute, Sync
> vs
> Parse, Describe statement, Sync, Bind, Execute, Sync
Sync is a resync point after a
Hi,
For an extended query that needs to get parameter types before sending
them, is there a difference in doing:
Parse, Describe statement, Flush, Bind, Execute, Sync
vs
Parse, Describe statement, Sync, Bind, Execute, Sync
Of course, there will be an additional ReadyForQuery in the latter case,
