>> 3) 3-rd boolean column (amopopr, amopfamily, amoporder)
>> - could be two records per operator
>> + operator could be used in both roles
>> + strategy number could be different for different roles
> How can #3 work at all? It's ignoring a couple of critical index
> columns. In particular, I believe the sticking point here is this
> unique index:
>
> "pg_amop_fam_strat_index" UNIQUE, btree (amopfamily, amoplefttype, amoprighttype, amopstrategy)
>
I believe, that columns (amoplefttype, amoprighttype) are fixed for operation
and could not be changed. So, two operations in one opfamily should be differ in
strategy number for different roles. It also gives a direct way to transfer
knowledge abot role to consistent method of GiST.
> I'm not terribly thrilled with using a boolean here in any case.
> Now that we have two "roles" an operator might play in an opclass,
> who's to say there might not be more roles someday? We should use
> a column type that will support more than two roles without basic
> rejiggering.
It's easy to change to char type, for now only 's'search and 'o'order characters
will be allowed.
> BTW, have we discussed the idea of embedding the role in the strategy
> number? For example, require regular operators to have strategy
In this schema, one operator could not be used in more than one role. Right now
it's not strict limitation, because the we still don't have an example of
boolean distance.
Anyhow, it needs to distinguish roles while IndexPath is built. So,
op_in_opfamily/get_op_opfamily_strategy/get_op_opfamily_properties and friends
will accept extra argument pointing to interested role.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/