... however, if you want to do some of the legwork yourself, here are
the ideas I had about what to do:
pg_opclass should have, not just one row for each distinct opclass name,
but one row for each supported combination of index AM and opclass name.
Doing it this way would allow us to put additional info in pg_opclass
rows --- right now, they're not really able to carry much information.
The particular bit of info I want to add is a "keytype" column. If this
is not InvalidOid then it gives the OID of the index column datatype to
be used when this opclass is selected. For keytype to be different from
data type, the amproc entries associated with the opclass would need to
include a conversion routine to produce the index value given the input
data columns --- ie, what the GIST code calls a compression routine.
(In essence, this would be a form of functional index, no?) Possibly
pg_opclass should also include the amprocnum of the conversion routine;
not sure how that ought to be handled.
Note that this change would have a number of implications for the
indexing of not only pg_opclass, but pg_amop and pg_amproc as well.
In particular, pg_amop could lose its amopid column, and pg_amproc
its amid column, since the opclass OID would be sufficient to indicate
which index AM is meant for any row in these tables. I have not worked
out all the details, but I believe that these tables would become a lot
more understandable this way.
As for lossiness, I'm inclined to remove that column from pg_index
altogether. Instead, it should be a column in pg_amop, indicating that
an index must be treated as lossy *for a particular operator in a
particular opclass*. Per previous discussion, this is the right level
for the concept. AFAIR, we could drop the WITH clause from CREATE INDEX
altogether if we did this, which I think is the right thing --- the user
should not be responsible for telling the system the properties of an
index type and opclass.
If you have time to start working out the details, that'd be great.
I won't have time for it before mid-August probably.
regards, tom lane