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.