Message-ID: <00b501c10386$00ab1e80$4301a8c0@directi.com>
From: "Arsalan Zaidi" <azaidi@directi.com>
To: "Barry Lind" <barry@xythos.com>
Cc: "PostgreSQL jdbc list" <pgsql-jdbc@postgresql.org>,
	"Bruce Momjian" <pgman@candle.pha.pa.us>
References: <200106301642.f5UGgkj14915@candle.pha.pa.us>
	<3B3E7A94.209@xythos.com>
	<00b801c102c4$fdd49ea0$4301a8c0@directi.com>
	<3B409F8F.7050408@xythos.com>
Subject: Re: [INTERFACES] New code for JDBC driver
Date: Tue, 3 Jul 2001 11:25:38 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>
> Why do you consider semi colons outside of quotes to be an error
condition?
>
> It is legal under postgresql to execute multiple SQL statements under
> one call to the server.  For example you can execute:
>
> update foo set bar = ?; select * from foo;

I agree that it probably is. Unfortunately, as I mentioned in my previous
post,no one is going to be entering in SQL queries directly through our
interface. We're not doing it and if someone is, he's up to no good. e.g.

"update users set name='"+name+"'"

If there's a text box in which you enter your name for the first query, I
can some fun if I enter in

Arsalan'';update funds set money = 100000 where userid =10

Am I right? It's situations like these that I'm trying to prevent. Is there
a better way?

The client will not be under our control. We're providing an API in the
middle which is called by our resellers. We have to perform some checking on
our side.

>
> As to your second point about escapeSQL escaping quotes, I don't see
> anywhere in the JDBC spec that says that type of behavior is supposed to
> happen.  Do you have an example where you feel the behavior of the
> escapeSQL method isn't conforming to the JDBC spec with regards to quote
> handling?

In the JDBC docs (from the Sun docs, java.sql -> Statement), it says that
setEscapeProcessing() will turn on the auto escaping of queries. In the
code, setEscapeProcessing sets escapeProcessing to true. In executeQuery, if
escapeProcessing is true, connection.escapeSQL is called. In
connection.escapeSQL, the string's quotes are *not* escaped. In fact, if I
remember in an earlier query, all there was, was a lone return sql;
statement.

I'm not familiar with the specs, so I could be wrong, but going on the docs
available to me, it seems to me that connection.escapeSQL should do more
than it's doing...

Thanks for listening! :-)

--Arsalan.