Re: Rule recompilation

On Thu, 12 Jul 2001, Jan Wieck wrote:

> Alex Pilosov wrote:
> > I remember awhile ago, someone floated the idea of a dependency view which
> > would list all objects and what OIDs they have in their plan. (i.e. what
> > do they depend on).
> >
> > I'm definitely no expert in this, but to me, one possible implementation
> > would be to enhance outfuncs to provide for creation tracking of all
> > OIDs used in plan, and allow caller to receive this list and do something
> > with it. This would actually be very simple, as only _outOidList will need
> > to be modified...(but then again, I'm known for oversimplifying things :)
> >
> > Then, we can add ev_depends/oidvector to pg_rewrite and store the
> > dependency there, and for stored procedures, add a prodepends/oidvector to
> > pg_proc.
> >
> > Then, create union of pg_rewrite and pg_proc to list dependencies.
> >
> > Then, we would be able to provide warning when an object is dropped:
> > 'The following objects depend on this blah blah', and possibly an action
> > "alter database fixdepends oid" which would recompile everything that
> > depends on that oid.
> >
> > How's this sound?
>
> Er - oversimplified :-)
Yeah, most of my ideas end up like that, however see below ;)
>
> I remember it well, because Bruce is mentioning it every so
> often and constantly tries to convince me to start a project
> about a dependency table. I just think it's better not to do
> it for 7.2 (didn't we wanted to have that released THIS
> year?).
>
> Anyway, there's alot more to look at. Functions can be
> referenced in views, indexes, operators, aggregates and maybe
> more places. Views/rules can reference allmost any object.
> And this only builds the permanent cross reference.

For views, the necessary information (what does a view depend on) is in
pg_rewrite anyway, which we can track with my proposal.

For indices/operators/aggregates, pg_depends view may simply union the
necessary information from the existing tables, no additional tracking is
necessary. (example, if index depends on a proc, we already have that proc
oid as indproc).

If you are talking that tracking nested dependencies is hard, I don't
disagree there, its a pain to do recursive queries in SQL, but the
solution is to have (non-sql) function list_deep_depend(oid) which would
recurse down the pg_depend and find what depends on an object...

> We have to take a look at runtime information, telling which
> prepared/saved SPI plan uses a particular object and trigger
> automatic re-prepare for the plan in case.
This doesn't bother me that much. Restart of postmaster is an acceptable
thing to clear [really strange] things up.

I'm actually not looking for 100% recompilation when an underlying object
is changed, I'm looking for 100% reliable dependency information and a
warning listing all objects that will break if I delete an object.

Your proposal (automatic recompilation for rules) is orthogonal (but
related) to what I'm suggesting. Having an ability to recompile a rule is
great. Having an ability to see what rules depend on a given object is
also great. Having an ability to recompile all rules that depend on a
given object is even better ;)

Having an ability to recompile _everything_ that depends on a given object
is priceless, but we can take that one step at a time, first tackling
rules...

> 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? So basically we'd need some sort of pg_dump
> snippet associated with every object and issue an internal
> DROP/CREATE using that string to recompile it.

Which may not be all that hard now, as most things that pg_dump does now
are integrated in the backend, and all pg_dump does is call an appropriate
function (ala pg_get_viewdef/pg_get_ruledef). But I am content leaving it
for the next time, tackling rules for now.