Re: Proposal - asynchronous functions

On 04/26/2011 04:22 PM, Stephen Frost wrote:

> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Tue, Apr 26, 2011 at 8:32 AM, Stephen Frost<sfrost@snowman.net>  wrote:
>>> Well, this specific thing could be done by just having PG close the
>>> client connection, not care that it's gone, and have an implied
>>> 'commit;' at the end.  I'm not saying that I like this approach, but I
>>> don't think it'd be hard to implement.
>> Maybe, but that introduces a lot of complications with regards to
>> things like authentication.  We probably want some API for a backend
>> to say - hey, please spawn a session with the same user ID and
>> database association as me, and also provide some mechanism for data
>> transfer between the two processes.
> The impression I got from the OP is that this function call could be the
> last (and possibly only) thing done with this connection.  I wasn't
> suggesting that we spawn a new backend to run it (that introduces all
> kinds of complexities).  The approach I was suggesting was to just have
> the backend close its client connection and then process the function
> and then 'commit;' and exit.
>
My thought was that it actually would require its own process. One use 
case is a function might be called from within another function, but it 
does not want to wait for a return. Then the original function would 
finish processing and return. The second function would be run with the 
security of the user who called the function, but would be "managed" as 
a separate connection without a client (or as a client on the server to 
be more precise)

Sim