Re: best way to determine start of new statement within a function? (resend) - Mailing list pgsql-hackers

From elein
Subject Re: best way to determine start of new statement within a function? (resend)
Date
Msg-id 20030725102408.C3643@cookie
Whole thread Raw
In response to Re: best way to determine start of new statement within a function?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: best way to determine start of new statement within
List pgsql-hackers
The semantics of this conceptually is not too
bad.  The implementation could be tricky.

For any given DML or sub-DML (select, eg) the scope
should be for that DML. The DML is the "parent"
of the function.  The DML is the statement
context and the function is the function
context.

statement --> function              |              + --> statement --> function                                   |
                             + --> statement
 
statement --> function1, function2              |           |              |           +--> statement -> function3
       |                                |              |                                +--> statement              |
          |              |              + --> statement --> function4                                   |
                   + --> statement
 

For example:

select myfunc() from foo; -- 1 statement


select myfunc() from  (select myfunc2() from foo);  -- subselect ( select ): both actually     have the same memory
duration,but have different     statement contexts and different function contexts.  -- the scope of each matches its
select

select myfunc() from foo;  --where myfunc invokes select myfunc2() from bar;
The scope of myfunc is the parent select.
The scope of myfunc2 resets at each iteration of
myfunc(), but is available for each iteration of
itself.  Note that these things can nest very
deeply.

select myfunc() from foo where myfunc3() = 't';  -- both myfunc() and myfunc3() have the same     statement parent.  --
ifmyfunc3() invoked select * from myfunc4()     then each iteration of myfunc3() resets the     statement context of
thatselect.
 

The new statement corresponds to a single invocation
of one DML. Memory should last through the whole
invocation loop.

Am I making sense here?

Where does the function context info memory get
available for allocation and where does it
get deallocated?  (It does get deallocated
via garbage collection, right?) I think the scope
of this is correct.

We implemented this at informix and got a lot of
stuff wrong.  Memory pool hell, but we had to deal
with a multi-threaded server.  Illustra did
it right so I think postgres already has the handles to
the hook the memory into the right scope.

Do you want me to try to write this up into
more formal definitions?

elein


On Fri, Jul 25, 2003 at 12:53:11AM -0400, Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> > Specifically I'd like to reset a variable within my PL/R interpreter 
> > each time a new SQL statement begins.
> 
> Define "new SQL statement".  In particular, what of a PL function
> executing multiple SQL statements inside an outer SQL statement that
> invoked the function?  Unless you've got a clear idea of the semantics
> you want, it's not going to be very profitable to discuss
> implementations ...
> 
>            regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faqs/FAQ.html
> 


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Anyone going to Linux World Expo SF?
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Datetime patch