Re: Sync vs Flush

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 query protocol breaks down the above-described simple
query protocol into multiple steps."
- "[Only] At completion of each series of extended-query messages, the
frontend should issue a Sync message."
- "A Flush [and not Sync] must be sent [...] if the frontend wishes to
examine the results of that command before issuing more commands."
- "The simple Query message is approximately equivalent to the series
Parse, Bind, portal Describe, Execute, Close, Sync."

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?

Jaka

On Thu, Jul 2, 2020 at 12:41 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> =?UTF-8?B?SmFrYSBKYW7EjWFy?= <jaka(at)kubje(dot)org> 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 an error, so the real question is what
> you want to have happen if you get some kind of error during the Parse.
> If you expect that the app wouldn't proceed with issuing Bind/Execute
> then you want to do it the second way.
>
> I suppose you could do
>
> Send Parse/Describe/Flush
> Read results
> If OK:
> Send Bind/Execute/Sync
> else:
> Send Sync # needed to get back to normal state
>
> but that doesn't sound all that convenient.
>
> regards, tom lane
>