On Wed, Jul 23, 2014 at 12:07 PM, Ben Hood <[email protected]> wrote:
> Or have I just been looking at the wrong version of the spec all along?
So it turns out that this is a case of PEBCAK: v2 of the protocol is
formulated thusly:
4.2.5.4. Prepared
The result to a PREPARE message. The rest of the body of a Prepared result is:
<id><metadata><result_metadata>
where:
- <id> is [short bytes] representing the prepared query ID.
- <metadata> is defined exactly as for a Rows RESULT (See section
4.2.5.2; you
can however assume that the Has_more_pages flag is always off) and
is the specification for the variable bound in this prepare statement.
- <result_metadata> is defined exactly as <metadata> but correspond to the
metadata for the resultSet that execute this query will yield. Note that
<result_metadata> may be empty (have the No_metadata flag and 0
columns, See
section 4.2.5.2) and will be for any query that is not a Select. There is
in fact never a guarantee that this will non-empty so client
should protect
themselves accordingly. The presence of this information is an
optimization that allows to later execute the statement that has been
prepared without requesting the metadata (Skip_metadata flag in EXECUTE).
Clients can safely discard this metadata if they do not want to take
advantage of that optimization.
Note that prepared query ID return is global to the node on which the query
has been prepared. It can be used on any connection to that node and this
until the node is restarted (after which the query must be reprepared).
Sorry for the noise on the list.
