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" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
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.
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
