Oleg Bartunov <oleg@sai.msu.su> writes:
> 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 ?
There's a fair amount of code that would need to be touched. One thing
I realized just last night is that some routines use the tables to ask
questions like "is this operator OID a member of any btree opclass, and
if so which opclass and strategy number?" This is a relatively simple
sequential scan over the pg_amop table at the moment. But if the amid
column were removed, it'd require a join with pg_opclass, which might be
good from the point of view of normalization theory but is a bit of a
pain in the neck to program in low-level code. It might also be nice if
we could use an index instead of a seq scan (although pg_amop is not so
large that this is essential). So all the places that touch these
tables need to be identified, and a design invented that doesn't make
any of them unreasonably complex.
Possibly we should leave the amid column in pg_amop, ie, deliberately
keep the tables unnormalized, to make some of these lookups easier.
> 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.
Okay, so the presence of a non-null keytype field should indicate that a
conversion routine is to be invoked, even if it's the same type as the
underlying datatype.
regards, tom lane
