> > Why is it possible in Oracle' world? -:)
> 
>     Because of there limited features?

And now we limit our additional advanced 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?

At the time of creation function body could be parsed and referenced
objects stored in system table (or function could be marked as dirty
and referenced objects would stored at first compilation and after
each subsequent successful after-dirtied-compilation).
Isn't it possible for PL/_ANY_L_ too?

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

Sure.

Vadim

Thu, 12 Jul 2001 11:23:56 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Rule recompilation
Mikheev, Vadim wrote:
> > > Why is it possible in Oracle' world? -:)
> >
> >     Because of there limited features?
>
> And now we limit our additional advanced 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?
>
> At the time of creation function body could be parsed and referenced
> objects stored in system table (or function could be marked as dirty
> and referenced objects would stored at first compilation and after
> each subsequent successful after-dirtied-compilation).
> Isn't it possible for PL/_ANY_L_ too?

    Nonononono!

    PL/Tcl  is  a very good example for that. To load a function,
    basically a "proc" command is executed in a Tcl  interpreter.
    But  execution  of  Tcl's  "proc"  command  doesn't cause the
    bytecode  compiler  to  kick  in  and  actually   parse   the
    procedures  body.  So  until  the  first  actual  call of the
    function, the Tcl interpreter just holds  a  string  for  the
    body.   Now  a  procedure  body in Tcl is basically a list of
    commands with possible sublists. On call,  only  the  topmost
    level  of this list hierarchy is parsed and compiled, command
    per command. Plus recursively those sublists, needed for this
    invocation.

    You  cannot control Tcl's bytecode compiler from the outside.
    There's no API for that. And Tcl is  a  dynamic  language.  A
    function might execute dynamic code found in some user table?

    Since we don't save bytecode for PL objects,  these  all  are
    IMHO runtime dependencies and most of them could be solved if
    we fix SPI to deal with it correctly.


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:00:44 -0400 (EDT)
Jan Wieck <JanWieck@Yahoo.com>
Re: Rule recompilation
Jan Wieck <JanWieck@Yahoo.com> writes:
>     You  cannot control Tcl's bytecode compiler from the outside.

An excellent example.  You don't *need* to control Tcl's bytecode
compiler from the outside, because *Tcl gets it right without help*.
It takes care of the function-text-to-derived-form dependency
internally: when you redefine the function, the internal form is
discarded and rebuilt.  You don't have to worry about it.

What everyone else is telling you is that we should strive to do the
same, not punt and make the user tell us when to recompile.

			regards, tom lane

Thu, 12 Jul 2001 15:50:42 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Rule recompilation 
Tom Lane wrote:
> 
> Jan Wieck <JanWieck@Yahoo.com> writes:
> 
> What everyone else is telling you is that we should strive to do the
> same, not punt and make the user tell us when to recompile.
> 

In Oracle, objects like views, functions and triggers are
just marked INVALID when an object to which they make
reference is changed. INVALID objects are recompiled when
they are needed. in particular, if a table was dropped and
a table is created with the same name then the objects which
make reference (directly/indirectly) to the table would
revive.
We would have to reconsider *alter table .. rename ..* ..

regards,
Hiroshi Inoue

Fri, 13 Jul 2001 09:42:19 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: Rule recompilation
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> We would have to reconsider *alter table .. rename ..* ..

Yeah, that's one thing that would act differently if we adopt my idea of
considering the source text of the rule to be the primary definition.
It's not clear if this is good or bad, however.  Consider:

	create table foo (f1 int, f2 text);

	create view v1 as select f1 from foo;

	alter table foo rename column f1 to fx;

	alter table foo rename column f2 to f1;

At this point, what would you expect v1 to return, and why?  How
would you justify it in terms of "what the user would expect",
as opposed to "what we can conveniently implement"?

Another interesting case is:

	create table foo (f1 int, f2 text);

	create view v1 as select * from foo;

	alter table foo add column f3 float;

Should v1 now have three columns?  If not, how do you justify it?
If so, how do you implement it (v1 has already got its pg_attribute
rows)?

Messy any way you look at it, I fear.  But clearly my idea needs
more thought ...

			regards, tom lane

Thu, 12 Jul 2001 21:37:18 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Rule recompilation 
Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > We would have to reconsider *alter table .. rename ..* ..
> 
> Yeah, that's one thing that would act differently if we adopt my idea of
> considering the source text of the rule to be the primary definition.
> It's not clear if this is good or bad, however.  Consider:
> 
>         create table foo (f1 int, f2 text);
> 
>         create view v1 as select f1 from foo;
> 
>         alter table foo rename column f1 to fx;
> 
>         alter table foo rename column f2 to f1;
> 
> At this point, what would you expect v1 to return, and why?  How
> would you justify it in terms of "what the user would expect",
> as opposed to "what we can conveniently implement"?
> 

The view v1 is INVALIDated by the first ALTER command.
It is still INVALID after the second ALTER command.
When *select * from v1* is called, the re-compilation 
would translate it into *select f1(originally f2) from foo*.
The behavior is different from that the current.
The current *reference by id* approach is suitable
for the current *rename* behavior but *reference by
name* approach isn't. *rename* isn't that easy from
the first IMHO.

> Another interesting case is:
> 
>         create table foo (f1 int, f2 text);
> 
>         create view v1 as select * from foo;
> 
>         alter table foo add column f3 float;
> 
> Should v1 now have three columns? 

Yes. We could create the view v1 as *select f1, f2 
from foo* from the first if we hate the side effect. 

> If not, how do you justify it?
> If so, how do you implement it (v1 has already got its pg_attribute
> rows)?
> 

Isn't the creation of pg_attribute tuples a part of
(re-)compilation ?

regards,
Hiroshi Inoue

Fri, 13 Jul 2001 11:16:55 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: Rule recompilation