>>> > I've been attempting to port applications from Pervasive SQL to PG.
>>> > Pervasive is interesting because it runs on top of btrieve. This allow
>>> > legacy apps
>>> > and SQL systems to co-exist. It's quirky and buggy, but it's better
than PG
>>> > because it can do the following.
>>> >
>>> >
>>> > 1. Have more than 7 fields on a btree index
>>>
>>> We have never understood why someone would want an index with more than
>>> seven columns.

Legacy apps, Bruce. Sometimes you come across tables with ten fields in the
index. I'm working on a (fairly specialised) system now where the primary
key of one of the tables has twenty-four fields in it. It is a summary
table, and probably not the best design, but that's the way it is, and I
have to live with it. Unfortunately, because we don't have a database that
can have that many fields in a key, we have to construct manual indices in
code. Even Oracle (which is what we are using) only goes up to about 21 or
something. However, if you are going to summarise heavily, then the number
of fields in your primary key can get quite large.
How difficult would it be to make the number of fields in an index unlimited
(or arbitrarily large). Perhaps there could be a compile-time variable
which is defaulted to 7, but which can be increased using the configure
script (./configure --with-index-fields=24). I realise that there are
performance issues, but that's a trade off that only the system designers
can make.

MikeA...