Re: binary protocol, again

On Friday 20 July 2012, you wrote:
> You should be hunting for semicolons in the query with knowledge of
> comments (single line, multiline, nested), strings (including
> dollar-quoted strings, unicode-escape, standard-conforming)... It
> seems a painful road.

I follow the "better safe than sorry" approach: if the query has anything
after a semicolon, it /could/ be a multi-query case and will failover.
Usually, user input should only appear in parameters so cannot introduce a
semicolon into the query string.

> Great :) Sorry though, I haven't got it: have you decided introducing
> now the cursor_bin, hence you don't need parsing the query to see if
> it's eligible or were you already using the cursor_bin? In the latter
> case, why are you parsing the query and not always using PQexecParams?

cursor_bin /tries/ to use the binary protocol, but may still fail over into
the text one, if the queries are not eligible.
It is just a way of apps to say "yes, I want to go binary".
If you think about it, there is cases where we may need to mix PQexecParams
and PQexec in the same transaction, using the same pythonic cursor. So, that
class must be capable of both types of call.

The other thing is binary *results*. Using a different cursor clearly indicates
that the application agrees to get the results in binary (ie. I won't break
the world without asking), so we could set 'cursor_bin' to use that even for
PQexec calls.

> Lovely (not bikeshedding about the name: the important is the
> protocols to be distinct)

A note here: I'm planning to use the *same* adapter classes for both the
ISQLQuote and ISQLParam usages. I think it would be ugly to have two types of
BINARY, two types of CHAR etc. Here, you can say that if your parameters are
adapted to [CHAR, CHAR, INTEGER] you can go PQExecParams, while if they are
non adaptable like [CHAR, CHAR, MYFOO] it has to failover.

WDYT?

--
Say NO to spam and viruses. Stop using Microsoft Windows!