Re: Is this a bug, possible security hole, or wrong assumption?

Mike Mascari <mascarm(at)mascari(dot)com> writes:
> What appears to me is that the rewriter is just tacking the IS NULL test
> onto the parsed query. As a result, a function is called with data from
> a view before the evaluation of IS NULL removes those rows from the
> selection process. Is that right? If so, is that a security problem?

You're essentially asking for a guarantee about the order of evaluation
of WHERE clauses. There is no such guarantee, and won't be because it
would be a crippling blow to performance. For example, consider

create table tab (k int primary key, d text);
create view v as select * from tab where d is not null;
select * from v where k = 42;

If the not-null clause must be evaluated before the outer where,
then this query will be unable to use an indexscan on k. See related
discussion a week or so ago (in pgsql-general if memory serves).

We could possibly tweak the optimizer so that the where-clauses pulled
up from the view are evaluated first in cases where there is no
plan-driven reason to do it the other way 'round, but I doubt this would
provide much security.

regards, tom lane