Jan Wieck <JanWieck@Yahoo.com> writes:
> For most objects, there is no such "recompile" possible - at
> least not without storing alot more information than now.
> Create a function and based on that an operator. Then you
> drop the function and create another one. Hmmm, pg_operator
> doesn't have the function name and argument types, it only
> knows the old functions oid. How do you find the new function
> from here?
What new function? The correct system behavior (as yet unimplemented)
would be to *drop* the operator the instant someone drops the underlying
function.
What is more interesting here is an (also unimplemented, but should
exist) ALTER FUNCTION command that can replace the definition text
of an existing function object. The link from the operator to the
function then does not change --- but we'd like to cause cached plans,
etc, to be rebuilt if they depend on the old function definition via
the operator.
I think it's wrong to see the problem as relinking primary definitions
to point at new objects. The primary definition of an object does not
need to change, what we need is to be able to update derived data.
pg_rewrite is currently broken in the sense that it's not storing a
primary definition (ie, rule source text).
regards, tom lane