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