Re: Problems with question marks in operators (JDBC, ECPG, ...)

On Tue, May 19, 2015 at 8:04 PM, Greg Sabino Mullane <greg(at)turnstep(dot)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.