On Monday, 4 September 2017 at 15:59:47 UTC, denizzzka wrote:
>
Sorry fot duplicate answer

On Monday, 4 September 2017 at 16:05:17 UTC, denizzzka wrote:
> Sorry fot duplicate answer

Ok, just FYI, I guess what I described was implemented in libpq for version 9.6 (but works on any PSQL since 8.4, since they all implement extended query protocol i wrote the client for) in a form of
https://2ndquadrant.github.io/postgres/libpq-batch-mode.html

It was possible before, just not in libpq. Same goes for binding multiple portals to one prepared (parsed) statement.

Since it's a quite new feature (1 year ago), derelict bindings should be updated. If I'll have a spare day, I'll try to do something with it.

On Monday, 4 September 2017 at 17:56:04 UTC, Boris-Barboris wrote:
> On Monday, 4 September 2017 at 16:05:17 UTC, denizzzka wrote:
>> Sorry fot duplicate answer
>
> Ok, just FYI, I guess what I described was implemented in libpq for version 9.6 (but works on any PSQL since 8.4, since they all implement extended query protocol i wrote the client for) in a form of
> https://2ndquadrant.github.io/postgres/libpq-batch-mode.html
>
> It was possible before, just not in libpq. Same goes for binding multiple portals to one prepared (parsed) statement.
>
> Since it's a quite new feature (1 year ago), derelict bindings should be updated. If I'll have a spare day, I'll try to do something with it.

After that I will add batch mode into dpq2.

On Monday, 4 September 2017 at 15:47:04 UTC, Boris-Barboris wrote:
> On Monday, 4 September 2017 at 15:40:47 UTC, denizzzka wrote:
>> This is just internal function. Don't try to call it from your application.
>
> I guess it's the Python curse
>
>> Oh... What is it:
>> PARSE + BIND + EXEC + SYNC
>> ?
> Yeah, that's what I do currently, just write the whole command chain (same goes for transaction control statement, they take 15-20 bytes before\after actual commands, so no need to send them separately) when it's built, flush it to socket and block until all results come back, finalized by ReadyForQuery message.

Probably, you don't need async socket operations here at all. Do not mix async sockets and async postgres operations.

Batch mode was added because new postgres protocol prohibits statements with separation by ; symbol, IMHO

On Monday, 4 September 2017 at 18:37:40 UTC, denizzzka wrote:
> On Monday, 4 September 2017 at 15:47:04 UTC, Boris-Barboris wrote:
>> On Monday, 4 September 2017 at 15:40:47 UTC, denizzzka wrote:
>>> This is just internal function. Don't try to call it from your application.
>>
>> I guess it's the Python curse
>>
>>> Oh... What is it:
>>> PARSE + BIND + EXEC + SYNC
>>> ?
>> Yeah, that's what I do currently, just write the whole command chain (same goes for transaction control statement, they take 15-20 bytes before\after actual commands, so no need to send them separately) when it's built, flush it to socket and block until all results come back, finalized by ReadyForQuery message.
>
> Probably, you don't need async socket operations here at all.

Oops, my mistake. This is wrong.

On Monday, 4 September 2017 at 17:56:04 UTC, Boris-Barboris wrote:
> On Monday, 4 September 2017 at 16:05:17 UTC, denizzzka wrote:
>> Sorry fot duplicate answer
>
> Ok, just FYI, I guess what I described was implemented in libpq for version 9.6 (but works on any PSQL since 8.4, since they all implement extended query protocol i wrote the client for) in a form of
> https://2ndquadrant.github.io/postgres/libpq-batch-mode.html

Theese calls will be added in pq 10, not 9.6.

On Tuesday, 5 September 2017 at 03:22:37 UTC, denizzzka wrote:
> On Monday, 4 September 2017 at 17:56:04 UTC, Boris-Barboris wrote:
>> On Monday, 4 September 2017 at 16:05:17 UTC, denizzzka wrote:
>>> Sorry fot duplicate answer
>>
>> Ok, just FYI, I guess what I described was implemented in libpq for version 9.6 (but works on any PSQL since 8.4, since they all implement extended query protocol i wrote the client for) in a form of
>> https://2ndquadrant.github.io/postgres/libpq-batch-mode.html
>
> Theese calls will be added in pq 10, not 9.6.

Oh, my bad, I thought 9.6beta was a beta for 9.6.