Hi,
disallow more than one SQL statement per PQexec.
I agree, it would help.
1. Inexpensive to implement
Disabling literals wouldn't be much harder to implement I believe, but
I don't know the PostgreSQL internals.
2. Unlikely to break most applications;
That's true.
3. Closes off a
Hi,
How many people are using literals in Java?
Not sure if I understood the question... In Java most people use
constants (final static). 'Checkstyle' can find 'magic numbers' in the
source code.
If the constants feature was very important in SQL, people would have
requested it, and it would
Hi,
Constants are just convenience: instead of constants, user defined
functions can be used. This already works, however it's a bit verbose:
CREATE FUNCTION STATE_ACTIVE() RETURNS VARCHAR AS
$$ BEGIN RETURN 'active'; END; $$ LANGUAGE PLPGSQL;
Usage is almost the same:
SELECT * FROM USERS WHERE
Hi,
Meredith's libdejector
1) The last activity was 2005-12-17 :-(
2) From the docs: the techniques used ... are ... being explored for
patentability.
3) The tool validates the SQL statement. This is not required when
using parameterized queries.
4) An 'exemplar' query is required for each
Hi Martijn,
The problem is not only quotes. The problem is all kinds of user
input. For example: sql = SELECT * FROM ORDERS WHERE ORDER_ID = +
orderId; This is not a problem if orderId is a number. But what if
it's a String? For example 1 AND (SELECT * FROM USERS WHERE
Hi,
For PostgreSQL the 'disable literals' feature would be great
publicity: PostgreSQL would be the first only major database that has
a good story regarding SQL injection. Yes it's not the magic silver
bullet, but databases like MS SQL Server, Oracle or MySQL would look
really bad.
Hi,
As you know, SQL injection is the main security problem of databases today.
I think I found a solution: 'disabling literals'. Or you may call it
'enforcing the use of parameterized statements'. This means that SQL
statements with embedded user input are rejected at runtime. My
solution goes
