Re: Proposal - asynchronous functions
От | Stephen Frost |
---|---|
Тема | Re: Proposal - asynchronous functions |
Дата | |
Msg-id | 20110426132226.GI4548@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Proposal - asynchronous functions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Proposal - asynchronous functions
|
Список | pgsql-hackers |
* 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. Might be interesting as a way to prefix anything, ala: LAST delete from big_table; poof, client is disconnected, backend keeps running, etc. I don't know if that would really be useful to very many people or that it's something we'd really want to do but it's an interesting idea to be able to 'background' a process. I'm certainly all for the bigger projects of having a cron-like capability and/or being able to spawn off multiple backgrounded queries from a single connection. Thanks, Stephen
В списке pgsql-hackers по дате отправления: