RE: Limitations

> >>> > 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...
I forgot to add that a trigger to check for uniqueness on this table would
be quite slow (especially
without the required index), as about two million rows are being added
daily.

MikeA...