From: | Nicholas White <n(dot)j(dot)white(at)gmail(dot)com> |
---|---|
To: | Mikko Tiihonen <mikko(dot)tiihonen(at)nitorcreations(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Patch: Force Primitives |
Date: | 2013-03-25 19:40:25 |
Message-ID: | CA+=vxNZYNgYQFAr0GJFWOqJp89dr=WejYuOGm10Ni+tG-yY3Dg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
> So another patch for that would be nice.
I've attached a patch that fixes setPrepareThreshold; previously setting
the threshold to n would mean the n+1th query would be the first binary
one, and setting it to zero meant the binary protocol would never be used.
This means the first query of a statement could never use the binary
protocol. The patch makes setting the threshold to n mean the nth query is
binary, so setting it to 1 would make the first query use the binary
protocol. The patch includes some test cases that demonstrate this.
> The discussion got stuck on weather updates with feature flags, adding a
minor version number to the protocol or just wait for pg 10 to break the
protocol is the correct way to go forward.
That patch is pretty interesting - but maybe you could preserve
backwards-compatibility by making a new format type (so 0 is text, 1 is
binary and 2 is binary-with-implied-sizes). A new format type would give
you more flexibility; you could even use variable-length or run-length
encodings, or compression to represent (only large?) arrays.
Thanks -
Nick
Attachment | Content-Type | Size |
---|---|---|
set-prepare-threshold-bug.patch | application/octet-stream | 6.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2013-03-26 12:48:46 | Re: patch to avoid a NullPointerException |
Previous Message | Mikko Tiihonen | 2013-03-25 18:43:38 | Re: Patch: Force Primitives |