Maciek Sakrejda <msakrejda@truviso.com> writes:
> Since triggering the set of FEBE messages that leads to this was tied
> deep into the guts of JDBC, I opted for raw wire protocol. It looks
> like the following sequence of messages from the client leads to this
> result format mixup:
> 1. Parse, with statement name "S_1", sql "SELECT $1::int", and
> parameter type oid 0 (ask server to guess)
> 2. Describe "S_1"
> 3. Bind "S_1" to anonymous portal, with param formats [ 0 (text) ],
> param values [ '2' ], result formats [ 1 (binary) ]
> 4. Execute anonymous portal (returning all rows)
> 5. Sync
> I have not tried to narrow this further yet. This essentially
> reproduces what Radosław was seeing but outside of the JDBC driver.
> That is, the server responds with:
> 1. Parse completion
> 2. Parameter description, with type oids [ 23 ]
> 3. Row description, with empty table data, type oids [ 23 ], type
> length 4, type mod -1, and format 0 (text)
> 4. Bind completion
> 5. DataRow, with the result in binary, as requested, but not as
> described in message (3) above
> 6. Command completion & RFQ
AFAICS this isn't a bug. What you're issuing Describe against is the
prepared statement, not the portal. The result column formats are not
specified by a prepared statement, so Describe just returns zeroes for
them. Result column formats are specified by the Bind command, which
creates a Portal. If you'd issued the Describe against the Portal, you
should get back the correct format codes. Per the protocol
specification:
The Describe message (statement variant) specifies the name of an
existing prepared statement (or an empty string for the unnamed
prepared statement). The response is a ParameterDescription message
describing the parameters needed by the statement, followed by a
RowDescription message describing the rows that will be returned
when the statement is eventually executed (or a NoData message if
the statement will not return rows). ErrorResponse is issued if
there is no such prepared statement. Note that since Bind has not
yet been issued, the formats to be used for returned columns are not
yet known to the backend; the format code fields in the
RowDescription message will be zeroes in this case.
Now, if there's something in the JDBC driver that expects
DescribeStatement to return useful result format codes, that'd be
a bug in the driver.
regards, tom lane