Is this all addresssed?
> On Sat, 14 Jul 2001, Tom Lane wrote:
>
> > ... however, if you want to do some of the legwork yourself, here are
> > the ideas I had about what to do:
>
> OK. We'll dig into problem in august. At least we'll try.
> How many possible problems would arise after changing of pg_opclass ?
> Does existing code will handle this change somewhat automagically
> or we have to find and modify relevant code ?
>
> >
> > 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.
>
> compress/decompress isn't a type conversion. for example,
> gist__int*_ops. indexed values and keytype are both int4 one dimensional
> arrays and compress/decompress in this case do some real work.
>
>
> >
> > 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
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> >
>
> Regards,
> Oleg
> _____________________________________________________________
> Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> Sternberg Astronomical Institute, Moscow University (Russia)
> Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
> phone: +007(095)939-16-83, +007(095)939-23-83
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
>
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
