Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> These protocol operations are interoperable with the SQL-level commands
>> for prepared queries and cursors, in the sense that a prepared query or
>> open cursor can be created either way and then used either way.
>> (Alternatively we might think that this is a bad idea, and that
>> protocol-level operations should use a different namespace from SQL
>> commands, so that application-requested operations can't interfere with
>> state that the client-side library has set up. Any opinions?)
> Does this mean that a statement PREPAREd at the protocol level could be
> EXECUTEd at the sql level? If that's the case, I'd tend to agree it is a
> bad idea.
I'm of two minds about it. On the basis of flexibility and ease of
debugging I'd think that sharing one namespace is good. But I suppose
a client library that wants to defend itself against clueless
application programmers might prefer a separate namespace.
> I'd think that binary support at the protocol level would obsolete the
> need for the DECLARE BINARY CURSOR command.
Yeah, but making something obsolete is not the same as being willing to
remove it immediately. If we keep DECLARE BINARY CURSOR around, how
should it act?
> A related question: how difficult would it be to support the ability to
> specify specific attributes as binary, while the rest are not.
I'd prefer not to go there. It'd be messy and I don't see that it has
any use for common client libraries. (Remember that most of this
discussion has focused on serving client libs that don't want to know
very much about the queries they're passing on --- so how are they going
to know which columns to ask for in binary?)
regards, tom lane