This what I done is
1. Send bind
2. Put on stack the requested format types
3. On bind complete get requestedFormats from stack.
4. When execute is complete (or portal suspend) then, use requestedFormats
to change the field formats received from describe or previously cached.
I assume server can'
Thank you, but I think about this last night. Opening unnecessary portals
isn't good idea, similarly sending 2nd describe when statement was
prepared. Currently JDBC drivers doesn't make this. I think better will be
to store what format we had requested on stack, and then coerce those
formats when
Maciek Sakrejda writes:
>> 21:43:02.264 (26) FE=> Describe(statement=S_1)
> You're still doing the statement-flavor Describe. As Tom pointed out,
> this won't tell you the result types because it doesn't know them.
> Actually, technically if you issue a statement-flavor Describe *after*
> a Bind,
> 21:43:02.264 (26) FE=> Describe(statement=S_1)
You're still doing the statement-flavor Describe. As Tom pointed out,
this won't tell you the result types because it doesn't know them.
Actually, technically if you issue a statement-flavor Describe *after*
a Bind, the server does have this inform
Hm... I moved Bind before Describe, I now have
// Construct a new portal if needed.
Portal portal = null;
if (usePortal)
{
String portalName = "C_" + (nextUniqueID++);
portal = new Portal(query, portalName);
}
sendBind(query,
> OTOH, it seems possible that the JDBC driver might behave differently
> depending on whether parameter types were prespecified or not --- it
> might issue Describe earlier in order to get the parameter types,
> perhaps.
Ah. Bingo:
boolean describeStatement = describeOnly || (!oneShot &&
Maciek Sakrejda writes:
>> But to the last part of cited protocol specification, when I've sent message
>> with statement parameter's type int4, int8, varchar the format
>> field wasn't set to 0, but 1.
> I wasn't able to reproduce that with my standalone test case. When I
> changed the paramete
On Thu, 25 Nov 2010 11:28:02 -0800, Maciek Sakrejda
wrote:
>> So, to summarise, I shouldn't believe server DescribeRow (in context of
>> format), in this situation, but only I should look at this what I asked
>> for, isn't it? If I asked for columns in binary format, I need to do
>> binary reading
> So, to summarise, I shouldn't believe server DescribeRow (in context of
> format), in this situation, but only I should look at this what I asked
> for, isn't it? If I asked for columns in binary format, I need to do binary
> reading regarding what server has responded?
Yes, because in this ca
Hi,
Thank you for your response.
I would only ask to be sure...
So, to summarise, I shouldn't believe server DescribeRow (in context of
format), in this situation, but only I should look at this what I asked
for, isn't it? If I asked for columns in binary format, I need to do binary
reading regar
Okay, looking at the JDBC side of things, I think JDBC doesn't
actually need that information (since, it always used text results
before Radosław's patch--the previous binary support was for
parameters only, right?). From looking at QueryExecutorImpl
(specifically sendOneQuery), it's clear that it
Interesting. I think you're right. Looking at the Wireshark traffic
again, the driver seems to issue a portal-variant Describe when using
unnamed prepared statements, but as soon as the named prepared
statements kick in (per prepare threshold), the Describe is a
statement-variant Describe with the
Maciek Sakrejda 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
I checked against other parameter bindings and it looks like problem is
connected with oid=0.
In those cases:
1. Executing statement with parameter sent as varchar, int, long, with
text and binary format is ok.
2. Executing statement with oid=0 fail always; I've sent parameter in text
mode (encode
Haven't really gotten much further, but an interesting note: the named
/ unnamed prepared statement and portal stuff seems to be a red
herring. I can add a name to the portal, or move to an unnamed
prepared statement, and I still see the same thing. Which is
interesting, since that's not what Rados
I've run your test and I can confirm the error. I've looked at the
protocol traffic with Wireshark, and the back-end is clearly lying
about the format of the results in this particular case: as you
stated, the row description says text, but the data is in binary.
I also wrote a simple Java program
> Text format is marked as 0, binary format is 1.
Sorry--I misread the docs. This is consistent and something does look fishy.
Thanks for the tarball. I can take a look tonight.
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650) 242-35
I didn't described log correctly, 1st attached response is normal execution;
flags QUERY_SUPPRESS_BEGIN | QUERY_ONESHOT, 2nd is compiled statement
QUERY_SUPPRESS_BEGIN only.
Text format is marked as 0, binary format is 1.
The 1st shown execution (flags=17) is good, it tells that result is send
>Result is oid=23, format=(0) T, value = 0x00,0x00,0x00,0x02
What do you mean regarding the format? Are you just inferring that
from the data? If memory serves, the format of a particular column is
not specified anywhere other than the RowDescription, and according to
your JDBC log output above, t
19 matches
Mail list logo
