Re: Rule recompilation

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Alex Pilosov <alex(at)pilosoft(dot)com>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rule recompilation
Date: 2001-07-12 18:39:21
Message-ID: 200107121839.f6CIdLF05048@jupiter.us.greatbridge.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 :-)

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.

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.

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.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message P. Dwayne Miller 2001-07-12 18:45:09 select count...
Previous Message Tom Lane 2001-07-12 18:37:23 Re: Re: Strangeness in xid allocation / snapshot setup