
The attached tiny patch (not intended for application yet) provides a 
space for plperl functions to create and share session persistent data, 
which I should think would increase the utility of plperl. Essentially 
it creates a hash called %session_globals which it then injects into the 
safe container where plperl functions live.

Comments are welcome - this is just a proof of concept. If this seems 
good to people, I will try to use a similar mechanism to "register" 
plperl functions so they can call each other.

cheers

andrew

(stupid) example use (using dollar quoting in psql ;-) ):

andrew=# create function perlfunc() returns text language plperl as $$
andrew$# if (!exists $session_globals{x}) { $session_globals{x} = 
'abcxyz'; }
andrew$# return $session_globals{x}++;
andrew$# $$;
CREATE FUNCTION
andrew=# select perlfunc();
 perlfunc
----------
 abcxyz
(1 row)

andrew=# select perlfunc();
 perlfunc
----------
 abcxza
(1 row)

andrew=# create function perlfunc2() returns text language plperl as $$
andrew$# if (!exists $session_globals{x}) { $session_globals{x} = 
'abcxyz'; }
andrew$# $session_globals{x} = reverse $session_globals{x};
andrew$# return $session_globals{x}++;
andrew$# $$;
CREATE FUNCTION
andrew=# select perlfunc2();
 perlfunc2
-----------
 bzxcba
(1 row)

andrew=# select perlfunc2();
 perlfunc2
-----------
 bbcxzb
(1 row)

andrew=# select perlfunc();
 perlfunc
----------
 bbcxzc
(1 row)



Sun, 08 Feb 2004 12:33:40 -0500
Andrew Dunstan <andrew@dunslane.net>
session persistent data for plperl
What about transactions? Let's say the first call was in a transaction
that's been rolled back. Semantically, that means the call never happened.
If you maintain the session data in a table, everything is fine of course.
But if it's in memory the solution has some rather nasty implications to it.

This is one scenario where I think it would be useful if the backend
provided some transaction callback mechanisms (discussed in this group
earlier under topic "Transaction callback"). That would enable the
implementation of "transaction aware session persistent data" in memory.

Regards,

- thomas

"Andrew Dunstan" <andrew@dunslane.net> wrote in message
news:402672F4.4050905@dunslane.net...
>
> The attached tiny patch (not intended for application yet) provides a
> space for plperl functions to create and share session persistent data,
> which I should think would increase the utility of plperl. Essentially
> it creates a hash called %session_globals which it then injects into the
> safe container where plperl functions live.
>
> Comments are welcome - this is just a proof of concept. If this seems
> good to people, I will try to use a similar mechanism to "register"
> plperl functions so they can call each other.
>
> cheers
>
> andrew
>
> (stupid) example use (using dollar quoting in psql ;-) ):
>
> andrew=# create function perlfunc() returns text language plperl as $$
> andrew$# if (!exists $session_globals{x}) { $session_globals{x} =
> 'abcxyz'; }
> andrew$# return $session_globals{x}++;
> andrew$# $$;
> CREATE FUNCTION
> andrew=# select perlfunc();
>  perlfunc
> ----------
>  abcxyz
> (1 row)
>
> andrew=# select perlfunc();
>  perlfunc
> ----------
>  abcxza
> (1 row)
>
> andrew=# create function perlfunc2() returns text language plperl as $$
> andrew$# if (!exists $session_globals{x}) { $session_globals{x} =
> 'abcxyz'; }
> andrew$# $session_globals{x} = reverse $session_globals{x};
> andrew$# return $session_globals{x}++;
> andrew$# $$;
> CREATE FUNCTION
> andrew=# select perlfunc2();
>  perlfunc2
> -----------
>  bzxcba
> (1 row)
>
> andrew=# select perlfunc2();
>  perlfunc2
> -----------
>  bbcxzb
> (1 row)
>
> andrew=# select perlfunc();
>  perlfunc
> ----------
>  bbcxzc
> (1 row)
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>



Sun, 8 Feb 2004 18:54:48 +0100
"Thomas Hallgren" <thhal@mailblocks.com>
Re: session persistent data for plperl
I wrote:

>
> The attached tiny patch (not intended for application yet) provides a 
> space for plperl functions to create and share session persistent 
> data, which I should think would increase the utility of plperl. 
> Essentially it creates a hash called %session_globals which it then 
> injects into the safe container where plperl functions live.
>

...and the patch is attached here
Sun, 08 Feb 2004 13:04:54 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: session persistent data for plperl
"Thomas Hallgren" <thhal@mailblocks.com> writes:
> "Andrew Dunstan" <andrew@dunslane.net> wrote:
>> The attached tiny patch (not intended for application yet) provides a
>> space for plperl functions to create and share session persistent data,

> What about transactions?

AFAICS, Andrew is just emulating a feature that has always existed in
pltcl.  Insisting that the plperl version must have intelligence not
found in the pltcl version seems like raising the bar unfairly.

			regards, tom lane

Sun, 08 Feb 2004 14:00:05 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: session persistent data for plperl 

As Tom Lane noted, pltcl already allows this. In fact, it appears that 
plperl already allows functions to create their own session-persistent 
data, but doesn't share data between functions.

I guess there's a philosophical question: should we apply transactional 
safety to (transient) data not stored in the database? I can see both 
sides of the argument, but have no motivation myself to provide such 
transactional safety, at least not now.

cheers

andrew


Thomas Hallgren wrote:

>What about transactions? Let's say the first call was in a transaction
>that's been rolled back. Semantically, that means the call never happened.
>If you maintain the session data in a table, everything is fine of course.
>But if it's in memory the solution has some rather nasty implications to it.
>
>This is one scenario where I think it would be useful if the backend
>provided some transaction callback mechanisms (discussed in this group
>earlier under topic "Transaction callback"). That would enable the
>implementation of "transaction aware session persistent data" in memory.
>
>Regards,
>
>- thomas
>
>"Andrew Dunstan" <andrew@dunslane.net> wrote in message
>news:402672F4.4050905@dunslane.net...
>  
>
>>The attached tiny patch (not intended for application yet) provides a
>>space for plperl functions to create and share session persistent data,
>>which I should think would increase the utility of plperl. Essentially
>>it creates a hash called %session_globals which it then injects into the
>>safe container where plperl functions live.
>>
>>Comments are welcome - this is just a proof of concept. If this seems
>>good to people, I will try to use a similar mechanism to "register"
>>plperl functions so they can call each other.
>>
>>    
>>
>  
>


Sun, 08 Feb 2004 14:52:17 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: session persistent data for plperl
I'm not insisting anything. I merely suggest something that all pl<lang>
implementations would have a potential benefit from.

But  perhaps I should insist. Both with respect to plperl, pltcl, or any
other pl<lang> where session data is possible. IMHO, session data spanning
more than one transcation is dangerous and error prone if it's not
coordinated with the transactions. Even if one can argue that, it's the
developers responsability to avoid the pitfalls, I still think its a bit
harsh to just disregard the benefits such mechanisms could gain by
transaction callback.

Regards,

- thomas

"Tom Lane" <tgl@sss.pgh.pa.us> wrote in message
news:4322.1076266805@sss.pgh.pa.us...
> "Thomas Hallgren" <thhal@mailblocks.com> writes:
> > "Andrew Dunstan" <andrew@dunslane.net> wrote:
> >> The attached tiny patch (not intended for application yet) provides a
> >> space for plperl functions to create and share session persistent data,
>
> > What about transactions?
>
> AFAICS, Andrew is just emulating a feature that has always existed in
> pltcl.  Insisting that the plperl version must have intelligence not
> found in the pltcl version seems like raising the bar unfairly.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html
>



Sun, 8 Feb 2004 20:56:24 +0100
"Thomas Hallgren" <thhal@mailblocks.com>
Re: session persistent data for plperl