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: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
