* Tom Lane (t...@sss.pgh.pa.us) wrote: > Alexander Korotkov <aekorot...@gmail.com> writes: > > My proposal is to let ALTER OPERATOR change restrict and join selectivity > > functions of the operator. Also it would be useful to be able to change > > commutator and negator of operator: extension could add commutators and > > negators in further versions. Any thoughts? > > I'm pretty dubious about this, because we lack any mechanism for undoing > parser/planner decisions based on operator properties. And there's quite > a lot of stuff that is based on the assumption that operator properties > will never change. > > An example of the pitfalls here is that we can never allow ALTER OPERATOR > RENAME, because for example if you rename '<' to '~<~' that will change > its precedence, and we have no way to fix the parse trees embedded in > stored views to reflect that. > > For the specific cases you mention, perhaps it would be all right if we > taught plancache.c to blow away *all* cached plans upon seeing any change > in pg_operator; but that seems like a brute-force solution.
Agreed that it is- but is that really a problem...? I've not run into
many (any?) systems where pg_operator is getting changed often... The
worst part would be adding new operators/extensions, but perhaps we
could exclude that specific case from triggering the cache invalidation?
Thanks!
Stephen
signature.asc
Description: Digital signature
