| 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: | Whole Thread | Raw Message | 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 |