May I change the API for operator selectivity estimators?

Will anyone object if I change the calling convention for operator
selectivity estimation functions (oprrest, oprjoin entries in
pg_operator)?

Historically the call conventions have been

double oprrest(Oid opid, Oid relid, AttrNumber attno,
Datum value, int32 flag);

double oprjoin(Oid opid, Oid relid1, AttrNumber attno1,
Oid relid2, AttrNumber attno2);

These are not only extremely restrictive (no chance to do anything
intelligent with clauses more complex than var op const or var op var),
but they force the estimator to re-look-up information that's already
readily available inside the planner, such as the type of the variables
in question.

I'd like to change these conventions to be like

double oprjoin(Query *root, Oid operator, List *args);

which would be more flexible and more efficient than the current
approach. I can see a couple of possible objections though:

1. This would break any user-written selectivity estimators that
might be out there. I kinda doubt that there are any, since we've
never really documented what these functions do or how to write one,
but if you've got one then speak up!

2. To do anything useful, functions called like this would have to be
coded in C (since higher-level languages would have no idea what the
struct datatypes are). In theory at least, one might have coded
estimator functions in PL languages or even SQL under the existing call
conventions. Again, though, I think this is a theoretical possibility
rather than something that's ever been done or is likely to be done.

Comments?

regards, tom lane