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.
>>
>>
>>
>
>
