~ubuntu-branches/ubuntu/natty/postgresql-8.4/natty-security : revision 1.1.4

9

*

10

*

11

* IDENTIFICATION

12

* $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.239 2009/04/16 20:42:16 tgl Exp $

12

* $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.240 2009/06/11 14:48:58 momjian Exp $

13

*

14

*-------------------------------------------------------------------------

15

*/

179

true, NULL, SAOP_FORBID, ST_ANYSCAN);

180

181

/*

182

* Submit all the ones that can form plain IndexScan plans to add_path.

183

* (A plain IndexPath always represents a plain IndexScan plan; however

184

* some of the indexes might support only bitmap scans, and those we

185

* mustn't submit to add_path here.) Also, pick out the ones that might

186

* be useful as bitmap scans. For that, we must discard indexes that

187

* don't support bitmap scans, and we also are only interested in paths

188

* that have some selectivity; we should discard anything that was

189

* generated solely for ordering purposes.

182

* Submit all the ones that can form plain IndexScan plans to add_path. (A

183

* plain IndexPath always represents a plain IndexScan plan; however some

184

* of the indexes might support only bitmap scans, and those we mustn't

185

* submit to add_path here.) Also, pick out the ones that might be useful

186

* as bitmap scans. For that, we must discard indexes that don't support

187

* bitmap scans, and we also are only interested in paths that have some

188

* selectivity; we should discard anything that was generated solely for

189

* ordering purposes.

190

*/

191

bitindexpaths = NIL;

192

foreach(l, indexpaths)

1628

1629

/*

1630

* If it's a btree index, we can reject it if its opfamily isn't

1631

* compatible with the EC, since no clause generated from the

1632

* EC could be used with the index. For non-btree indexes,

1633

* we can't easily tell whether clauses generated from the EC

1634

* could be used with the index, so only check for expression

1635

* match. This might mean we return "true" for a useless index,

1636

* but that will just cause some wasted planner cycles; it's

1637

* better than ignoring useful indexes.

1631

* compatible with the EC, since no clause generated from the EC

1632

* could be used with the index. For non-btree indexes, we can't

1633

* easily tell whether clauses generated from the EC could be used

1634

* with the index, so only check for expression match. This might

1635

* mean we return "true" for a useless index, but that will just

1636

* cause some wasted planner cycles; it's better than ignoring

1637

* useful indexes.

1638

*/

1639

if ((index->relam != BTREE_AM_OID ||

1640

list_member_oid(ec->ec_opfamilies, curFamily)) &&

2223

* want to apply. (A hash index, for example, will not support ">=".)

2224

* Currently, only btree supports the operators we need.

2225

*

2226

* Note: actually, in the Pattern_Prefix_Exact case, we only need "="

2227

* so a hash index would work. Currently it doesn't seem worth checking

2228

* for that, however.

2226

* Note: actually, in the Pattern_Prefix_Exact case, we only need "=" so a

2227

* hash index would work. Currently it doesn't seem worth checking for

2228

* that, however.

2229

*

2230

* We insist on the opfamily being the specific one we expect, else we'd

2231

* do the wrong thing if someone were to make a reverse-sort opfamily with

2460

/*

2461

* LIKE and regex operators are not members of any btree index opfamily,

2462

* but they can be members of opfamilies for more exotic index types such

2463

* as GIN. Therefore, we should only do expansion if the operator is

2463

* as GIN. Therefore, we should only do expansion if the operator is

2464

* actually not in the opfamily. But checking that requires a syscache

2465

* lookup, so it's best to first see if the operator is one we are

2466

* interested in.