On Tue, May 19, 2015 at 8:04 PM, Greg Sabino Mullane <g...@turnstep.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > Bruno Harbulot asked for a devil's advocate by saying: > > My main point was that this is not specific to JDBC. Considering that > even > > PostgreSQL's own ECPG is affected, the issue goes probably deeper than it > > seems. I'm just not convinced that passing the problem onto connectors, > > libraries and ultimately application developers is the right thing to do > > here. > > Well, one could argue that it *is* their problem, as they should be using > the standard Postgres way for placeholders, which is $1, $2, $3... > As I was saying in another message on this thread a few hours ago, it appears that ? is reserved for placeholders for Dynamic SQL according to the SQL specifications, and that would be exactly what ECPG is using as far as I understand. > > > Recommending that all drivers implement \? as a semi-standard workaround > is > > actually a much more difficult problem than it seems: it requires > following > > the development of each project, making the case to each community > > (assuming they're all open source), and reasonable in-depth knowledge of > > their respective implementation, also assuming that \? won't cause > further > > problems there (of course, all that is easier if you're already working > on > > that particular project). > > That's actually where we are right now. And it's not really our job to > make the case to each community - it is the responsibility of each project > to solve the problem, presumably because of pressure from their users. > ... except if those communities made the assumption that ? was indeed reserved for placeholders according to the SQL specifications. (I might have misinterpreted where that part of the spec is applicable, since I can't claim I've absorbed the entire set of documents.) > Even according to what you're saying this issue has required a first > > workaround back in 2008, and another one earlier this year, probably due > to > > concerns that weren't spotted when implementing the first workaround > (this > > also presumably requires users to run a fairly recent version of this > > connector now). > > True enough regarding the two changes. But the system worked well, in that > someone had a problem, raised a bug, and it got fixed. I'm not sure I see > the point about requiring recent versions of the connector - that's true > for lots of bug fixes and features. This one at least is fairly optional > with many existing workarounds (e.g. use $1, quote things in a different > way). > This model of development also requires the users to be able to upgrade their connectors to a recent release, which may also affect other dependencies (depending on the complexity of the overall system). Best wishes, Bruno.
