On Mon, 2006-07-10 at 12:22 +0200, Dirk Lutzeb=C3=A4ck wrote:

No, it's always worked like this.

The index can only be used if we know at plan time that the index
predicate is true for all times that the query is executed. We cannot
know this for the exact query and index combination you have requested.
If we acted differently, your query would return the wrong answer in
some circumstances.

I can't find anything in the manual that explains this distinction.

Here's an example that explains this more easily:

If your index looked like this

CREATE INDEX c_6000_index ON consumption (voi)=20
WHERE=20
code > 5000
AND val1 IS NULL;

and your query like this

UPDATE c=20
SET val1=3D1784=20
WHERE=20
( code > 6000
AND val1 IS NULL )
AND code =3D ?=20
AND voi =3D '1923328-8-0-0';

....then the index could be used, because the index predicate is implied
by part of the query clause for all values of the parameter.

So its best to look for some other static definition of the index.

I'll submit a doc patch.

--=20
Simon Riggs
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On Mon, 2006-07-10 at 13:35 +0200, Dirk Lutzeb=C3=A4ck wrote:

That's not what I said. I see no security problem as a result of this
behaviour.

--=20
Simon Riggs
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Hi,

On Mon, 10 Jul 2006, [UTF-8] Dirk Lutzeb=E4ck wrote:

DBD::Pg only recently started preparing queries in the server.

Older versions of DBD::Pg simulated prepared statements behind the
scenes so your postgresql server got to plan every query individually.

You might want to switch of server side prepares for your specific=20
query and see if that helps. See the description of the pg_server_prepare
in the DBD::Pg manpage on how to go about this.

I hope you are not relying on prepared statements as your only
defense against sql code injection.

Greetings
Christian

--=20
Christian Kratzer ck (AT) cksoft (DOT) de
CK Software GmbH http://www.cksoft.de/
Phone: +49 7452 889 135 Fax: +49 7452 889 136
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly