Re: Remove columns pg_index.haskeytype and pg_index.indisclustered

> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > I have removed pg_index.haskeytype and pg_index.indisclustered with the
> > > following patch. They were not used.
> >
> > haskeytype IS used, by GIST. Kindly revert this entire patch.
>
> Fixing now. Thanks.

Patch applied. Field re-added. (I removed it incorrectly anyway.)

What threw me off is that there was a comment saying the field was not
used.

How does GIST set this field? Does GIST insert directly into pg_index?
I don't see this field set anywhere except to 'true'. Here are the
references I see from the 7.1.X code:

./backend/access/gist/gist.c: giststate->haskeytype = itupform->indhaskeytype;
./backend/access/gist/gist.c: if (giststate->haskeytype)
./backend/access/gist/gist.c: if (giststate->haskeytype)
./backend/access/gist/gist.c: if (giststate->haskeytype)
./backend/catalog/index.c: indexForm->indhaskeytype = true; /* not actually used anymore */
./include/access/gist.h: bool haskeytype;
./include/catalog/pg_index.h: * first variable length field. so I moved indislossy, indhaskeytype,
./include/catalog/pg_index.h: bool indhaskeytype; /* does key type != attribute type? */
./include/catalog/pg_index.h:#define Anum_pg_index_indhaskeytype 8

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026