Commits

Tom Lane
committed
e2c2c2e2011-12-23

Improve planner's handling of duplicated index column expressions.

It's potentially useful for an index to repeat the same indexable columnor expression in multiple index columns, if the columns have differentopclasses. (If they share opclasses too, the duplicate column is prettyuseless, but nonetheless we've allowed such cases since 9.0.) However,the planner failed to cope with this, because createplan.c was relying onsimple equal() matching to figure out which index column each index qualis intended for. We do have that information available upstream inindxpath.c, though, so the fix is to not flatten the multi-level indexqualslist when putting it into an IndexPath. Then we can rely on the subliststructure to identify target index columns in createplan.c. There's asimilar issue for index ORDER BYs (the KNNGIST feature), so introduce amulti-level-list representation for that too. This adds a bit morerepresentational overhead, but we might more or less buy that back by nothaving to search for matching index columns anymore in createplan.c;likewise btcostestimate saves some cycles.

Per bug #6351 from Christian Rudolph. Likely symptoms include the "btreeindex keys must be ordered by attribute" failure shown there, as well as"operator MMMM is not a member of opfamily NNNN".

Although this is a pre-existing problem that can be demonstrated in 9.0 and9.1, I'm not going to back-patch it, because the API changes in the plannerseem likely to break things such as index plugins. The corner cases wherethis matters seem too narrow to justify possibly breaking things in a minorrelease.