Excellent, thanks!
On Sat, Jul 11, 2020 at 8:43 PM Tom Lane wrote:
> =?UTF-8?B?SmFrYSBKYW7EjWFy?= writes:
> > I wrote a Postgres client and in it I allow the user to specify arbitrary
> > StartupMessage parameters (Map). This is convenient
> because
> > the user can for example set search_path
Hi,
I wrote a Postgres client and in it I allow the user to specify arbitrary
StartupMessage parameters (Map). This is convenient because
the user can for example set search_path without issuing a separate SET
query or encoding things into the "options" parameter. The protocol
documentation also s
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
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
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,
