> > In good world rules (PL functions etc) should be automatically
> > marked as dirty (ie recompilation required) whenever referenced
> > objects are changed.
> 
>     Yepp,  and  it'd  be possible for rules (just not right now).
>     But we're not in  a  really  good  world,  so  it'll  not  be
>     possible for PL's.

Why is it possible in Oracle' world? -:)

Vadim

Thu, 12 Jul 2001 10:55:30 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Rule recompilation
Mikheev, Vadim wrote:
> > > In good world rules (PL functions etc) should be automatically
> > > marked as dirty (ie recompilation required) whenever referenced
> > > objects are changed.
> >
> >     Yepp,  and  it'd  be possible for rules (just not right now).
> >     But we're not in  a  really  good  world,  so  it'll  not  be
> >     possible for PL's.
>
> Why is it possible in Oracle' world? -:)

    Because of there limited features?

    Think  about  a  language like PL/Tcl. At the time you call a
    script for execution, you cannot even be sure  that  the  Tcl
    bytecode  compiler parsed anything, so how will you ever know
    the complete set of objects referenced from this function?

    And PL/pgSQL? We don't prepare all the  statements  into  SPI
    plans  at  compile  time. We wait until the separate branches
    are needed, so how do you know offhand here?

    In the PL/pgSQL case it *might* be possible. But is it  worth
    it?


Jan

--

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



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


Thu, 12 Jul 2001 14:12:14 -0400 (EDT)
Jan Wieck <JanWieck@Yahoo.com>
Re: Rule recompilation
On Thu, 12 Jul 2001, Jan Wieck wrote:

> Mikheev, Vadim wrote:
> > > > In good world rules (PL functions etc) should be automatically
> > > > marked as dirty (ie recompilation required) whenever referenced
> > > > objects are changed.
> > >
> > >     Yepp,  and  it'd  be possible for rules (just not right now).
> > >     But we're not in  a  really  good  world,  so  it'll  not  be
> > >     possible for PL's.
> >
> > Why is it possible in Oracle' world? -:)
> 
>     Because of there limited features?
> 
>     Think  about  a  language like PL/Tcl. At the time you call a
>     script for execution, you cannot even be sure  that  the  Tcl
>     bytecode  compiler parsed anything, so how will you ever know
>     the complete set of objects referenced from this function?
>     And PL/pgSQL? We don't prepare all the  statements  into  SPI
>     plans  at  compile  time. We wait until the separate branches
>     are needed, so how do you know offhand here?
If plan hasn't been made (oid has not been referenced), does it really
depend on an object?

>     In the PL/pgSQL case it *might* be possible. But is it  worth
>     it?
It'd be possible in general, as long as pl compilers properly keep track
what their objects depend on in pg_proc. (as in my above email).

-alex 


Thu, 12 Jul 2001 14:30:28 -0400 (EDT)
Alex Pilosov <alex@pilosoft.com>
Re: Rule recompilation
Jan Wieck <JanWieck@Yahoo.com> writes:
>     And PL/pgSQL? We don't prepare all the  statements  into  SPI
>     plans  at  compile  time. We wait until the separate branches
>     are needed, so how do you know offhand here?

If we haven't prepared a statement yet, then we don't need to reprepare
it, hmm?  So it'd be sufficient to keep track of a list of all objects
referenced *so far* by each plpgsql function.

Your complaints about pltcl and plperl are irrelevant because they don't
save prepared plans.  For the languages that do save prepared plans, it
seems possible to keep track of a list of all objects that each plan
depends on.  So I think that we should try to do it right, rather than
assuming from the start that we can't.

>     In the PL/pgSQL case it *might* be possible. But is it  worth
>     it?

Yes.  If we're not going to do it right, I think we needn't bother to do
it at all.  "Restart your backend" is just as good an answer, probably
better, than "issue a RECOMPILE against everything affected by whatever
you changed".  If the system can't keep track of that, how likely is it
that the user can?

			regards, tom lane

Thu, 12 Jul 2001 14:55:42 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Rule recompilation 
Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>
> >     In the PL/pgSQL case it *might* be possible. But is it  worth
> >     it?
>
> Yes.  If we're not going to do it right, I think we needn't bother to do
> it at all.  "Restart your backend" is just as good an answer, probably
> better, than "issue a RECOMPILE against everything affected by whatever
> you changed".  If the system can't keep track of that, how likely is it
> that the user can?

    Stop!

    We're talking about two different things here.

    Recompilation  (or  better  fixing  Oid  references in system
    catalog entries) is required to correct a system catalog that
    got  inconsistent due to dropping and recreating a particular
    object.

    Regeneration of runtime things like saved SPI plans might  be
    related  to  that, but it's not exactly the same. That surely
    is corrected  by  restarting  the  backend.  But  you  cannot
    correct a broken view with a backend restart, can you?

    And  pardon,  but  PL/Tcl can save SPI plans. At least it had
    that capability when I wrote the language handler, so  if  it
    cannot any more WHO DID THAT?


Jan

--

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



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


Thu, 12 Jul 2001 15:18:15 -0400 (EDT)
Jan Wieck <JanWieck@Yahoo.com>
Re: Rule recompilation
Jan Wieck <JanWieck@yahoo.com> writes:
>     Stop!
>     We're talking about two different things here.

You're right: fixing obsoleted querytrees stored in pg_rewrite and
similar catalogs is not the same thing as invalidating cached
query plans in plpgsql, SPI, etc.

However, we could turn them into the same problem if we rearrange the
catalogs to store only source text.  Then there's no need to update any
permanent state, only a need to cause invalidation of derived state
inside various backends.

Each piece of derived state could (and should IMHO) be tagged with a
list of all the objects it depends on; then an invalidation message for
any of those objects would cause that piece of state to be thrown away
and rebuilt at next use.  Just like the catalog caches ...

			regards, tom lane

Thu, 12 Jul 2001 15:33:08 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Rule recompilation 
IMHO we are trying to have a compiled language behave like an interpreted 
language.
This is a bottom to top approach with no real future. Here is a proposal of 
a top to bottom approach.

What we do in pgAdmin is that we store objects (functions, views and 
triggers) in separate tables called Development tables.
The production objects (which you are talking about) are running safe 
*without* modification. At any moment, it is possible to recompile the
development objects (functions, triggers and views modified by the user) 
from development tables.

pgAdmin then checks dependencies a goes through a whole compilation process.
BUT ONLY AT USER REQUEST.

Who would honestly work on a production server? This is too dangerous in a 
professional environment.
In a near future, we will offer the ability to store PostgreSQL objects on 
separate servers (called code repository).

You will then be able to move objects from the development server to the 
production servers. Think of replication.
Also, pgAdmin will include advanced team work features and code serialization.

pgAdmin is already an *old* product as we are working on exciting new things:
http://www.greatbridge.org/project/pgadmin/cvs/cvs.php/pgadmin/help/todo.html

Before downloading pgAdmin from CVS, read this:
http://www.greatbridge.org/project/pgadmin/cvs/cvs.php/binaries/readme.html

We are looking for feedback and help from the community.
Greetings from Jean-Michel POURE, Paris, France



Thu, 12 Jul 2001 23:07:24 +0200
Jean-Michel POURE <jm.poure@freesurf.fr>
Re: Rule recompilation 