I have been cleaning up the index-related code a little bit while
trying to eliminate memory leaks associated with functional indexes,
and I have noticed an old "feature" that I think we should remove.
It's undocumented (I'd never even heard of it before) and as far as
I can tell the only thing you can do with it is shoot yourself in the
foot.
What I'm talking about is the "opt_type" clause in CREATE INDEX
column items:
index_elem: attr_name opt_type opt_class
func_index: func_name '(' name_list ')' opt_type opt_class
opt_type: ':' Typename { $$ = $2; } | FOR Typename { $$ =
$2;} | /*EMPTY*/ { $$ = NULL; } ;
This is not to be confused with the index operator class option.
What it seems to do is override the system's choice of the size and
storage type of the index column --- the index is created as though
its stored column has the specified type, not the type of the
underlying data column or function result. Mind you, no actual
runtime data conversion is performed, we just cause the index's
catalog entries to lie about what's in the column.
I can see no possible use for this except triggering coredumps.
Whatever functionality might be served by pretending the column type
is different from reality is already taken care of by the ability
to override the index operator class for the column. Furthermore,
as of 7.0 the opclass code contains safety checks to prevent you from
substituting operators on a non-binary-compatible datatype. There are
no checks whatever on the "opt_type" substitution.
Unless someone comes up with a good reason for this feature,
it's going to be history very shortly.
regards, tom lane
