Re: More protocol discussion: breaking down query processing

Tom Lane wrote:
> The existing Q"sql statement" command can now be thought of as a macro
> that invokes PARSE, BIND no parameters, DESCRIBE cursor, FETCH all from
> cursor, CLOSE, DEALLOCATE.

This makes good sense to me.

> 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 am inclined to think also that the FETCH operation should allow
> specification of whether it wants the results in text or binary form.
> It's not real clear how that should interoperate with the existing
> DECLARE BINARY CURSOR command, though --- which one should win if there's
> a conflict?

I'd think that binary support at the protocol level would obsolete the
need for the DECLARE BINARY CURSOR command.

A related question: how difficult would it be to support the ability to
specify specific attributes as binary, while the rest are not. The
reason this would be useful is that you might want to receive bytea
fields in binary, but not have to deal with binary-to-string conversion
of other fields.

> A difficulty with this scheme is that it doesn't scale very well to
> querystrings containing more than one SQL statement. For the all-in-one
> query command, we can just define that the BIND-DESCRIBE-FETCH-CLOSE cycle
> is automatically repeated for each parsetree constructed from the string;
> this is backwards-compatible with what happens now. It seems fairly messy
> to extend that to the case where the steps are individually commanded ...
> especially if you want to assume that the steps are being commanded by a
> client library that hasn't parsed the querystring and doesn't know how
> many commands exist therein. Perhaps we can get away with disallowing
> multiple commands per string when using the extended protocol.

I think disallowing multiple commands is probably the way to go, but I
guess you could make the interim results into arrays of interim results
instead.

Joe