On 04/26/2011 04:22 PM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Apr 26, 2011 at 8:32 AM, Stephen Frost<sfr...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
