On 19 May 2015 at 15:02, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Greg Sabino Mullane" <g...@turnstep.com> writes: > > Dave Cramer opined: > >> It would seem that choosing ? for operators was ill advised; I'm not > >> convinced that deprecating them is a bad idea. If we start now, in 5 > years > >> they should be all but gone > > > Ha ha ha ha ha! That's a good one. We still have clients on Postgres 7! > > Five years is way too short to replace something that major. > Yeah, that's a big problem for this line of thought. Even if we had > consensus today, the first release that would actually contain alternative > operators would be 9.6, more than a year out (since 9.5 is past feature > freeze now). It would take several years after that before there would be > any prospect of removing the old ones, and several years more before PG > versions containing the old operators were out of support. > > Now there are different ways you could look at this. From the perspective > of a particular end user, you could imagine instituting a shop policy of > not using the operators containing '?' as soon as you had a release where > there were alternatives. So in that context you might have a fix > available as soon as 9.6 came out. But from the perspective of a driver > author who has to support queries written by other people, the problem > would not be gone for at least ten years more. Changing the driver's > behavior sounds like a more practical solution. > > The current JDBC driver doesn't really support anything beyond 8.4 except for CRUD operations.
We are also are no longer supporting JVM's older than 1.6 in the current driver. People who insist on staying on old code get what they get. I don't see a problem with saying after a certain date we just don't support it in the current code. After all I have heard rumblings about deprecating V2 protocol ? FWIW, I was content to leave this alone. JDBC has a workable solution. However I've not seen a good argument for continuing to use the ? operator as it's conflicts with many clients and is apparently not in the SQL standard. Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca >
