Re: Planned changes to pg_am catalog

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: oleg@sai.msu.su, 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 majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

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